Method and apparatus for extending the range of the universal serial bus protocol

ABSTRACT

The present invention provides a method and apparatus to be used to extend the range of standard USB devices, and in particular, USB devices operating in accordance with Revision 2.0 of the USB Specification. An extended range hub is provided which comprises a Local Expander (LEX) and a Remote Expander (REX) which can be separated by up to, for example 100 meters. The LEX and REX operate in accordance with an enhanced high-speed USB Extended Range Protocol (USB-ERP) which permits USB devices to be more conveniently located and used, and is in compliance with Revision 2.0 of the USB Specification.

FIELD OF THE INVENTION

This method and apparatus relates to transmitting signals betweendevices using Universal Serial Bus ports, and in particular, to allowingcommunications between devices using such ports over an extended range.

DESCRIPTION OF THE RELATED ART

Universal Serial Bus (USB) is a peripheral interface for attachingpersonal computers to a wide variety of devices, such as, for example,digital telephone lines, monitors, modems, mice, printers, scanners,game controllers, keyboards, and the like. The creation of USB is acollaborative effort of seven of the largest companies in the computerand communication industry: namely Intel, Compaq, Microsoft, NorTel,NEC, Digital and IBM. The specifications defining USB (e.g. Intel etal., Universal Serial Bus Specification, Revision 1.0, January 1996; andupdated as Revision 1.1 in September 1998, and further updated asRevision 2.0 in April 2000, and subsequent updates andmodifications—hereinafter collectively referred to as the “USBSpecification”, which term can include future modifications andrevisions) are non-proprietary and are managed by an open industryorganization known as the USB Forum. The USB Specification establishesthe basic criteria that must be met in order to comply with USBstandards. The USB Specification also defines a number of terms andtheir definitions. These terms and definitions are to be used for thepurposes of this specification, unless otherwise stated.

As an example, it is a requirement of Revision 1.0 of the USBSpecification that a single USB domain shall support up to 127 devicesoperating over a shared medium providing a maximum bandwidth of 12 Mbps.Revision 2.0 increases the maximum bandwidth to 480 Mbps whilemaintaining compatibility with devices manufactured under the criteriaof Revision 1.1;—thus demonstrating ongoing modification of the USBSpecification. Under the USB Specification, a Host Controller thatsupports only a maximum signalling rate of 12 Mbps is referred to as afull-speed host and the transmission of signals from such a hostcontroller is restricted to a full-speed bus. A Host Controller thatsupports a signalling rate of 480 Mbps is referred to as a high-speedhost and said host controller transmits its signals on a high-speed bus.A full-speed Host Controller under the USB Specifications supports twoclasses of devices, namely, low-speed and full-speed devices. Ahigh-speed Host Controller conforming to the USB Specifications supportsthree classes of devices, namely, low-speed, full-speed, and high speeddevices. Low-speed devices have a maximum signalling rate of 1.5 Mbps,full-speed devices have a maximum signalling rate of 12 Mbps, andhigh-speed devices have a maximum signalling rate of 480 Mbps.

Under the current USB Specifications, including Revision 2.0, thedistance that a device can be separated from its host PC is limited to 5meters. By using a series of USB Hubs—devices that are intended tosupport increased populations rather than increased distances—thisdistance limitation can be increased, in theory, to 30 meters. Usingfive hubs and six 5-meter cables, placed between the hubs, to support asingle device at a range of 30 meters is an expensive and clumsysolution since hubs are currently priced at about $50 US each and atleast two of the five hubs must be provided with electrical power underthis extension method. In addition, using standard 5-meter cablesbetween hubs would mean that some hubs might have to be placed ininsecure and inconvenient locations.

There is therefore a need for methods and apparatus to allow USB devicesto be positioned at greater distances from the host PC. For example, anuninterrupted distance of at least 100 meters is required forcompatibility with the standards governing the cabling of commercialbuildings (see, for example, TIA-568-A, Commercial BuildingTelecommunication Cabling Standard, Telecommunications IndustryAssociation, October 1995). Providing for an extended range capabilitywould also create new applications for USB devices as well asfacilitating existing ones. For example, a simple residential or SOHO(small office, home office) surveillance system could be constructed byconnecting consumer quality cameras to a central PC. An overhead mountedmonitor could be monitored from any office in a commercial building.Many other applications are possible.

Currently, the USB Specifications do not permit the use of extendedranges.

It also is a further requirement of the USB Specification that theaccess of each device to the shared communications bus is controlled bya single Host Controller. It is also specified that when a full-speedHost Controller instructs a particular device to place its informationon to the shared bus, the requested information must be received by theHost Controller within 16 full-speed bit-times of said Host Controllerissuing said instruction. Similarly, when a high-speed Host Controllerinstructs a particular device to place its information on to the sharedbus, the requested Information must be received by the Host Controllerwithin 736 high-speed bit-times of said Host Controller issuing saidinstruction. Restriction on the response time ensures that the USBSpecification provides for a high efficiency of bandwidth utilization bylimiting the period during which no information is being transmitted.However, these requirements also limit the physical range of USB devicessince one bit-time at 12 Mbps, which is one full-speed bit-time, isequivalent to the time taken for an electronic signal to traverseapproximately 17 meters of copper cable. One bit-time at 480 Mbps, whichis one high-speed bit-time, is equivalent to the time taken for anelectronic signal to traverse approximately 440 millimeters of cable.

Further, although the USB device must respond to a request from thefull-speed Host Controller within 16 full-speed bit-times, 7.5full-speed bit-times is allocated for delay within a full or low-speedUSB device and its associated 5 meter cable. This allocation retainsonly 8.5 full-speed bit-times at 12 Mbps for additional cable delay. Thetime represented by 8.5 full-speed bit-times is equivalent to the delayincurred by electronic signals in traversing approximately 144 meters ofcable. The distance travelled within the allowed time span forfull-speed is insufficient to satisfy the round trip cable length of 200meters required by the premise cabling specification.

For the high-speed Host Controller, a device must respond to the HostController within 736 high-speed bit-times and 217 high-speed bit-timesof the restricted response time of 736 high-speed bit-times is allocatedfor delay within a high-speed USB device and its 5 meter cable. Thisallocation, thus, retains 519 full-speed bit-times at 480 Mbps foradditional cable delay. The time represented by 519 high-speed bit-timesrepresents a distance of 227 meters of cable. However, according to theUSB Specifications, a high-speed host must also support full andlow-speed devices which operate under the full-speed bus. The timeallocated for delay within a full or low-speed USB device and itsassociated 5 meter cable is 7.5 full-speed bit-times which is equivalentto 300 high-speed bit-times. Therefore, in the case where data istransferred between a high-speed host and a full or low-speed USBdevice, only 436 bit-times is retained for additional cable delay. Thetime represented by 436 bit-times at 480 Mbps is equivalent to a cabledistance of 190 meters. In order to maintain compatibility with full andlow-speed devices, the maximum cable length for high speed is thenrestricted to 190 meters which does not meet the specified round tripcable length of 200 meters.

It is a further feature of the USB Specification that the USBSpecification (or protocol) partitions access to the shared bus intodiscrete units known as “frames”, for a full-speed host, and“microframes”, for a high-speed host. The duration of a frame is 1 mswhile that of a microframe is 125 _(μ)s. Eight microframes areequivalent to one frame.

Further, the USB Specification also requires that at least four separatetypes of data streams or “traffic” are recognized, namely isochronoustransfers, control transfers, interrupt transfers, and bulk transfers.

Isochronous data transfer is characterized as being a data transferwherein data flows essentially continuously, and at a steady rate, inclose timing with the ability of the receiving mechanism to receive anduse the incoming data. Thus, isochronous transfers are considered to be“time-relevant”.

This type of data transfer is distinguished from asynchronous datatransfer, which pertains to processes that proceed independently of eachother until a dependent process has to “interrupt” the other process,and synchronous data transfer, which pertains to processes in which oneprocess has to wait on the completion of an event in another processbefore continuing. These data transfer methods are said to benon-time-relevant. Instead, a correct response to any request isrequired.

In our co-pending PCT patent application No. PCT/CA00/00157 (publishedas WO00/49507 on Aug. 24, 2000), herein incorporated by reference, asystem for extending the range of the USB protocol is described whichallows for cable distances of over 100 meters to be achieved forconnecting USB devices.

For the purposes of the present invention, this previous method willhereinafter be referred to, in general, as the “USB Extended RangeProtocol”. This USB Extended Range Protocol (USB-ERP) provides a methodfor extending the distance between USB devices to distances over 100 m,and which is in compliance with all sections of Revision 1.0 of the USBSpecifications, and any earlier versions, with the exception ofdistances between devices.

Using this method, in one feature, the data stream was an isochronousdata stream, and in more general terms, was a time relevant data stream,wherein the first or the subsequent original, outgoing digital signalwas a request for time-relevant data, and preferably, for an isochronousdata stream.

Also, it was stated that the digital signal is stored. This storageperiod, and any other storage period referred to in the presentspecification, may be a very short time period. For example, in the casewhere the reply signal is received in time to respond to the originaldigital, the reply signal may be immediately forwarded with minimalstorage time.

Further, it was stated that the digital signals might be converted tosignals which are more suitable for transmission, and the transmissionsignals can be converted back to digital signals, on both the outgoingand incoming signals. This optional conversion step is only necessary ifthe digital signals are converted, for some reason, for transmissionpurposes. Otherwise, the digital signals can be sent in their originalform. For the purposes of the present specification, it should beunderstood, however, that the digital signals may be converted fortransmission purposes, but they will preferably be converted back to thesame, or a similar digital signal, when required.

Devices operating using the USB-ERP have met with commercial success.However, while the methods and devices described according to theUSB-ERP have been useful, modifications to the USB Specification havemade enhancement of the USB-ERP desirable. Thus, the improved ormodified features of the current USB Specifications, namely USB 2.0,require some enhancement of the previously described system in order toachieve optimum performance. In view of these modifications, the systempreviously described in PCT application No. PCT/CA00/00157, whileproviding acceptable performance, could benefit from providingadditional enhancements to improve performance when high-speed devicesare being used.

For example, in the current USB Specifications, the host controller mayinquire about the availability of space at a high-speed device endpointusing a PING special token. This mechanism allows the host to wait untilthere is enough space at the device endpoint before transmittingsubsequent data packets. The PING protocol reduces the amount of wastedbandwidth that is associated with downstream transfers of control andbulk data when the endpoint is not capable of accepting data. The PINGprotocol is only valid for bulk and control data transfers between ahigh-speed host and a high-speed device wherein data flows from the hostto the device. PING special tokens are transmitted in the same manner asa normal token packet. Also, the current revision of the USBSpecification requires compatibility between hosts and devices whichwere manufactured in accordance with the different USB SpecificationRevisions. For example, a high speed host must still be able to operatewhen using a full speed or low speed device.

Thus, it would still be desirable to provide further improvements to thetechnology by providing a method and apparatus for enabling datatransmission equipment, and in particular, time relevant ornon-time-relevant data transmission equipment utilizing the USBSpecification, to be used over an extended range. Accordingly, thecurrent invention therefore again uses the fundamental characteristicsof isochronous and asynchronous data transfer, and more generally anytime relevant or non-time-relevant data transmission, and the existenceof regular protocol frames and microframes in order to provide methodsand apparatus to enable data transmission over extended distances.

It is, therefore, an object of the present invention to provide methodsand apparatus to enable devices, hubs and controllers and other devicesthat conform to the USB Specification to communicate over distancesgreater than that currently permitted under said USB Specification.

It is a further object of the present invention that the extended rangebe achieved without the need for intermediate hubs, repeaters or othermethods of electronic signal regeneration.

It is a further object of the present invention that no hardware orsoftware changes need to be made to the existing devices, hubs, andcontrollers supported by the system, and in particular, to either theisochronous or asynchronous systems operating under the USBSpecification. The invention, thereby, may be incorporated into networkscomposed of both conventional range and extended range devices.

It is a further object of the present invention that the apparatus bevery cost effective, consistent with the broadest population of devicestargeted by the USB industry.

These and other objects of the invention, which will become apparentherein, are fully, or at least partially attained by the presentinvention as described hereinbelow.

SUMMARY OF THE INVENTION

Enhancement of the USB-ERP, previously disclosed is therefore desired.Accordingly, the present invention provides an enhanced high-speedmethod for transmitting a data stream between a host controller and aperipheral device over an extended distance in accordance with the USBExtended Range Protocol (hereinafter the “USB-ERP”), wherein said methodadditionally comprises modifications to allow for compliance withRevision 2.0 of the USB Specifications. Preferably, these enhancementsinclude, in general: providing range extension between high speeddevices, while maintaining compatibility between High-Speed devices andFull Speed or Low Speed devices; providing improved ability to handleinterrupt, control, bulk and isochronous transfers according to Revision2.0; and/or providing the ability to handle PING protocols.

Accordingly, the present invention provides an enhanced high-speedmethod of transmitting a data stream, with modifications to allow forcompliance with Revision 2.0 of the USB Specification, wherein saidenhanced high-speed USB-ERP comprises:

-   a. feeding a first original, outgoing digital signal from a host    controller to a local expander unit;-   b. optionally converting said outgoing digital signal into a    converted outgoing signal having a format suitable for transmission    over extended distances;-   c. transmitting either said outgoing digital signal or said    converted outgoing signal, as an outgoing transmission signal, over    a signal distribution system;-   d. receiving said outgoing transmission signal at a remote expander    unit,-   e. optionally converting said outgoing transmission signal to said    first original outgoing digital signal;-   f. delivering said first original outgoing digital signal from said    remote expander to at least one peripheral device;-   e. receiving, at said remote expander, a reply digital signal from    said peripheral device;-   h. optionally converting said reply digital signal Into a converted    reply signal having a format suitable for transmission over extended    distances,-   i. transmitting said reply digital signal or said converted reply    signal as a reply transmission signal over said signal distribution    system;-   j. receiving said reply transmission signal at said local expander;-   k. optionally converting said reply transmission signal to said    original reply digital signal;-   l. storing said reply digital signal as a stored reply digital    signal until the receipt of a subsequent original, outgoing digital    signal from said host controller, which subsequent signal is the    same as, or similar to, said first original outgoing digital signal;    and-   m. forwarding said stored reply digital signal to said host    controller in response to said subsequent original outgoing digital    signal.

The phrase “enhanced high-speed” is preferably to be used to state thatthe USB-ERP operates in accordance with Revision 2.0 of the USBSpecification (other than for separation distances between devices).This method can, therefore, allow for the speed advantages of high speedhost controllers and/or high speed devices to be utilized.

With respect to isochronous transfers, or more generally, time relevantdata streams, the enhanced high-speed USB-ERP method of the presentinvention allows for the transfer of isochronous data from both hostsand devices at the higher transfer rates allowed under Revision 2.0, andthus permits the high transfer rates of high speed devices and hostcontrollers to be utilized.

Thus, the present invention also provides an enhanced high-speed methodas described hereinabove, which method provides for the transmission ofisochronous data according to Revision 2.0 of the USB Specificationwherein isochronous data is transmitted from a peripheral device and isreceived by a host controller, said method comprising:

-   a. transmitting a request for isochronous data from a host    controller to a local expander,-   b. forwarding said request for isochronous data from said local    expander to a remote expander over a signal distribution system;-   c. delivering said forwarded request for isochronous data to at    least one peripheral device;-   d. transmitting the requested isochronous data from said peripheral    device to said remote expander,-   e. forwarding said requested Isochronous data from said remote    expander to said local expander over said signal distribution    system;-   f. storing said requested isochronous data in a packet buffer at    said local expander;-   g. transmitting a subsequent request for isochronous data from said    host controller to aid local expander;-   h. receiving said subsequent request for isochronous data at said    local expander; and

I. retrieving the stored isochronous data from said local expander;

II. delivering said stored isochronous data to said host controller;

III. forwarding said subsequent request for isochronous data from saidlocal expander to aid remote expander over said signal distributionsystem; and

IV. repeating steps (c) through (h) for said subsequent request and anyfurther subsequent requests for isochronous data.

Additionally, the method of the present invention also provide a methodas described hereinabove, wherein said method provides a method fortransmission of isochronous data according to the USB Specificationwherein isochronous data is transmitted from a host controller and isreceived by a peripheral device, said method comprising:

a) receiving, at a local expander, an original notification ofisochronous a host controller;

b) forwarding said original notification of isochronous data from saidlocal expander to a remote expander over signal distribution system;

c) receiving, at a remote expander, said forwarded original notificationof isochronous data;

d) delivering said forwarded notification of asynchronous data to atleast one peripheral device;

e) receiving, at a local expander, an original isochronous data packetfrom a host controller;

f) forwarding said original isochronous data packet from said localexpander to a remote expander over a signal distribution system;

g) receiving, at a remote expander, said forwarded original isochronousdata packet; and

h) delivering said forwarded original isochronous data packet to atleast one peripheral device.

Yet still further, the present invention also provides a method asdescribed hereinabove wherein additionally comprising the followingsteps after step (b), namely:

-   -   i. Determining whether said local expander already possesses        said requested isochronous data;    -   ii. Generating a synthetic data packet if no such requested        isochronous data is present; and    -   iii. Delivering said synthetic isochronous data to said host        controller.

Also, the method of the present invention provides a method as describedhereinabove additionally comprising the following steps after step (b),uniquely for data transfers conforming to the USB Specifications whereindata is transmitted from a high-speed host and is received by afull-speed device, namely:

-   -   i) Determining whether said local expander already possesses        said requested isochronous data;    -   ii) Generating a synthetic not-yet packet if no such requested        isochronous data is present; and    -   iii) Delivering said not-yet packet to said host controller.

With respect to non-time-relevant data streams, and in particular,asynchronous data streams, the present invention provides an enhancedhigh-speed method for transmission of asynchronous data according to theUSB Specification wherein asynchronous data is transmitted from aperipheral device and is received by a host controller, said methodcomprising:

a) receiving, at a local expander, an original request for asynchronousdata from a host controller;

b) forwarding said original request for asynchronous data from saidlocal expander to a remote expander over a signal distribution system;

c) receiving, at a remote expander, said forwarded original request forasynchronous data;

d) delivering said forwarded original request for asynchronous data fromsaid peripheral device;

e) receiving; at said remote expander, the requested asynchronous, datafrom said peripheral device;

f) forwarding said requested asynchronous data from said remote expanderto said local expander over said signal distribution system;

g) storing, in a packet buffer at said local expander, said requestedasynchronous data;

h) receiving, at said local expander, a subsequent request forasynchronous data from said host controller; and

i) retrieving the stored asynchronous data from said packet buffer;

ii) delivering said retrieved asynchronous data to said host controller;

i) receiving, at said local expander, an outgoing acknowledgment signalfrom said host controller,

j) absorbing, at said local expander, said outgoing acknowledgementsignal.

Further, the present invention also provides a method as describedhereinabove additionally comprising the following steps after step (b),namely:

-   -   i) Determining whether said local expander already possesses        said requested asynchronous data;    -   ii) Generating a negative acknowledgement packet if no such        requested asynchronous data is present; and    -   iii) Delivering said negative acknowledgement packet to said        host controller.

Still further, the present invention provides a method as describedhereinabove additionally comprising the following steps after step (b),generally for high bandwidth data transfers conforming to the USBSpecifications wherein data is transmitted from a high-speed host and isreceived by a high-speed device, namely:

-   -   a. Determining whether said local expander already possesses        said requested asynchronous data;    -   b. Generating a synthetic data packet if no such requested        asynchronous data is present; and    -   c. Delivering said synthetic asynchronous data to said host        controller.

When data is transmitted from a high-speed host, and is received by alow-speed or full-speed device, the method of the present invention alsoprovides the following steps after step (b), uniquely for data transfersconforming to the USB Specifications wherein data is transmitted from ahigh-speed host and is received by a low-speed or full-speed device,namely:

-   -   a. Determining whether said local expander already possesses        said requested asynchronous data;    -   b. Generating a synthetic not-yet packet if no such requested        asynchronous data is present; and    -   c. Delivering said synthetic not-yet packet to said host        controller.

Further, the method can also comprise the following steps after step(e), namely:

-   -   i) generating an acknowledgement packet at said remote expander;        and    -   ii) delivering said acknowledgement packet to said peripheral        device.

Interrupt transfers, control transfers, and bulk transfers are allcategorized by the USB Specifications as types of asynchronous datatransfer, and are all non-time-relevant data streams However, the maincharacteristic that distinguishes interrupt transfers from controltransfers and bulk transfers is periodicity. For example, in accordancewith the USB Specification, Revision 2.0, interrupt transfers haveguaranteed bandwidth on the shared bus and therefore can occur atregular time intervals. However, control transfers and bulk transferscan occur any time and can take place when the shared bus has unoccupiedbandwidth. Control transfers have very little guaranteed bandwidth onthe shared bus. Bulk transfers have no guaranteed bandwidth. Therefore,bulk transfers have the lowest priority on the shared bus and only takeplace when there is available bandwidth after the bandwidth required byall the other transfers has been accounted for.

Control transfers are characterized by having three transfer phases fortransmitting each set of inbound or outbound data and said transferphases are: the set-up phase, the data phase, and the status phase.

With respect to control and bulk transfers, which are treated as twospecial cases of asynchronous transfers wherein data requests from thehost controller are generated non-periodically or on an as-needed basis,the invention provides a enhanced high-speed USB-ERP additionallycomprising the following step after determining whether the localexpander already possesses said requested asynchronous data, namely:

a. Absorbing at said local expander said subsequent request forasynchronous data.

For the purposes of the present invention, the term “absorbing” is usedto describe a process wherein the software recognizes that theinformation stored is not essential, or is no longer essential, andtherefore simply removes the information from storage without passing iton to any further devices.

For interrupt transfers, which are a special case of asynchronoustransfers wherein data requests from the host controller are generatedperiodically, the present invention also provides a method according toan enhanced high-speed USB-ERP additionally comprising the followingsteps after step (h) above, uniquely for interrupt data transferswherein asynchronous data is transmitted from a peripheral device and isreceived by a host controller, namely,

a. Forwarding said subsequent request for asynchronous data from saidlocal expander to a remote expander over a signal distribution system;

b. Delivering said forwarded subsequent request for asynchronous datafrom said remote expander to said peripheral device; and

c. Receiving, at said remote expander, the requested asynchronous datafrom said peripheral device.

In a preferred embodiment, the present invention also provides a methodas described hereinabove with respect to the present invention, whichprovides an enhanced high-speed USB-ERP method for transmission ofasynchronous data according to the USB Specification, whereinasynchronous data is transmitted from a host controller and is receivedby a peripheral device, said method comprising:

-   -   a) receiving, at a local expander, an original notification of        asynchronous data from a host-controller,    -   b) forwarding said original notification of asynchronous data        from said local expander to a remote expander over a signal        distribution system;    -   c) receiving, at a remote expander, said forwarded original        notification of asynchronous data;    -   d) delivering said forwarded notification of asynchronous data        to at least one peripheral device;    -   e) receiving, at a local expander, an original asynchronous data        packet from a host controller;    -   f) forwarding said original asynchronous data packet from said        local expander to a remote expander over a signal distribution        system;    -   g) receiving, at a remote expander, said forwarded original        asynchronous data packet,    -   h) delivering said forwarded original asynchronous data packet        to at least one peripheral device;    -   i) receiving, at said remote expander, an inbound acknowledgment        packet from said peripheral device;    -   j) forwarding said inbound acknowledgment packet from said        remote expander to said local expander over said signal        distribution system;    -   k) storing, in a packet buffer at said local expander, said        inbound acknowledgment packet;    -   l) receiving, at said local expander, a subsequent notification        of asynchronous data from said host controller;    -   m) receiving, at said local expander, a subsequent asynchronous        data packet from said host controller; and        -   i) retrieving said stored inbound acknowledgment packet from            said packet buffer; and        -   ii) delivering said retrieved inbound acknowledgment packet            to said host controller.

In a further preferred embodiment, the method described hereinaboveadditionally comprises the following steps, namely:

i) Determining whether said local expander already possesses saidinbound acknowledgment packet;

ii) Generating a negative acknowledgment packet if no such inboundacknowledgment packet is present; and

iii) Delivering said negative acknowledgment packet to said hostcontroller.

For interrupt transfers, the invention provides the following stepsafter steps l) and m) described hereinabove, namely:

-   a. Forwarding said subsequent notification of asynchronous data and    asynchronous data packet from said local expander to a remote    expander over a signal distribution system;-   b. Delivering said forwarded subsequent notification of asynchronous    data and asynchronous data packet to said peripheral device;-   c. Receiving, at said remote expander, the inbound acknowledgement    packet from said peripheral device;-   d. Repeating steps (j) through (m) for said subsequent notification    and data packet and any further subsequent notifications of    asynchronous data and asynchronous data packets.

For control and bulk transfers, the invention provides the followingsteps after steps l) and m) described hereinabove, namely:

-   a. Absorbing at said local expander said subsequent notification of    asynchronous data and said subsequent asynchronous data packet.

With respect to both time-relevant and non-time relevant data streams, aguard time can be imposed after a data packet is transmitted from aremote expander to a USB device, which guard time is set to a value thatis dependent upon the transfer type of said transmitted data packet,said method comprising:

(a) Receiving, at a remote expander, an outbound data packet,

(b) Determining, at a remote expander, the transfer type of saidoutbound data packet,

(c) Forwarding said outbound data packet from said remote expander to aUSB device,

(d) Setting the value of a transmission guard timer to a value that isdependent upon said determined transfer type; and

(e) Inhibiting further outbound transmissions until said guard timer hasexpired.

In an additional feature, the present invention also provides a methodas described hereinabove with respect to the present invention, whereinsaid method provides an enhanced high-speed USB-ERP method for handlingthe PING flow control protocol, which is used uniquely for control andbulk data transfers wherein asynchronous data is transmitted from ahigh-speed host to a high-speed device, said method comprising:

-   -   a) receiving, at a local expander, a PING flow control probe        from a host controller;    -   b) forwarding said flow control probe from said local expander        to a remote expander over a signal distribution system;    -   c) receiving, at a remote expander, said forwarded flow control        probe;    -   d) delivering said forwarded flow control probe to at least one        high-speed peripheral device;    -   e) receiving, at remote expander, the requested reply from said        peripheral device;    -   f) receiving, at local expander, said requested reply;    -   g) storing, in a packet buffer at said local expander, said        requested reply;    -   h) receiving, at said local expander, a subsequent PING flow        control probe from said host controller; and        -   i) retrieving said stored reply from said packet buffer;        -   ii) delivering said retrieved reply to host controller,    -   i) absorbing, at said local expander, said subsequent flow        control probe.

In a preferred feature, the method also provides the followingadditional steps after step (b) described hereinabove, namely:

i) Determining whether said local expander already possesses saidrequested reply;

ii) Generating a negative acknowledgement packet if no such requestedreply is present;

iii) Delivering said negative acknowledgement packet to said hostcontroller.

Additionally, the present invention provides apparatus which are capableof providing the processing logic described hereinabove.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Although a number of signal distribution systems may be used, asdescribed hereinabove, preferably the signals are transmitted over asignal distribution system that utilizes fibre optic cabling. Using thismethod of device connection provides a low cost and effective means fordata transmission. However, in another embodiment of the system, signalscan be transmitted over coaxial cable, Unshielded Twisted Pair (UTP)cable or wire, shielded cable, or wireless transmission methods.

While the methods and apparatus of the present invention have generalutility in a variety of applications, it is of primary importance thatthe data transmission methods and apparatus of the present inventionallow for compliance with the USB Specification (with the exception ofthe distance requirements). In one embodiment, the original signal fromthe host controller is a request for data from a peripheral device. Theperipheral devices can include devices selected from cameras, keyboards,mice, monitors, speakers, and the like.

For time relevant (isochronous) data streams, and in particular, duringoperations utilizing the methods and apparatus of the present inventionin applications involving extended range transmissions, it is preferredthat the apparatus be capable of recognizing isochronous transfers, whenthey are received. The data contained within the isochronous transfer isthen stored within the system for a period of time.

Preferably, the data that is received during a particular time periodmay be stored and then transmitted in a following time period.Additionally, a further preferred embodiment of the present invention isthat isochronous transfers originating from a plurality of sources maybe stored, and retransmitted.

In the operation of a preferred embodiment of the current invention, ahost controller (which preferably is a PC) may issue a request to adevice for the transfer of isochronous data. The request is received bythe apparatus of the present invention, and retransmitted to the targetdevice. When the requested isochronous transfer response is received bythe apparatus from the target device, the isochronous data is storedwithin the internal memory of the apparatus. During a subsequent timeperiod, the host controller will again issue a request to the targetdevice for the transfer of isochronous data. The apparatus will againretransmit this request to the target device. In addition, however, theapparatus recognizes that it currently has isochronous data from thetarget device stored in its internal memory. The apparatus sends thisdata to the host controller within the 16 full-speed bit-time margin inthe case of a full-speed bus (or within the 736 high-speed bit-timemargin in the case of a high-speed bus) relevant to the current requestwithin the time period. In this manner, the apparatus uses datacollected in a previous time period to satisfy the response timerequirement of a current time period.

For time relevant data streams, the term “time period” preferably refersto a single “frame” (1 ms) in the case of a full-speed bus or“microframe” (125 _(μ)s) in the case of a high-speed bus, as defined inthe USB Specification.

When a packet is received from the target device, and no further requestfor data is received from the host controller, the last data packet orpackets received and stored (hereinafter the “vestigial” packets) arepreferably removed from the system so that they are not transmitted whenand if a further request is received from the host controller.Preferably, this is achieved by modification of the method describedhereinabove by additionally comprising the following stages, namely:

-   -   i) Detecting when a new time period has begun;    -   ii) Examining the properties of each packet buffer;    -   iii) Determining whether the data packet contained in said        examined packet buffer has been stored for at least the duration        of one complete time period;    -   iv) Discarding said contained data packet if said contained data        packet has been stored for the duration of at least one complete        time period; and    -   v) Repeating steps i) through iv) for each packet buffer in the        system.

In an alternative embodiment of the invention, the apparatus handles thefirst request for the inbound transfer of isochronous data in a uniquemanner. This unique manner requires the apparatus to generate its ownsynthetic inbound data packet.

It is possible that packets sent from the Remote Expander may not arriveat the Local Expander In the order expected by the Local Expander. Inorder to avoid difficulties that might be caused by this occurrence, themethod of the present invention also preferably comprises the followingstages, namely:

-   -   1) Storing the address of the requested peripheral device at        said remote expander after the local expander has delivered the        forwarded request for isochronous data; and further comprising        the following steps after transmitting the requested isochronous        data from the peripheral device to the remote expander, namely:        -   a) Retrieving the address of said requested peripheral            device at said remote expander unit; and        -   b) Adding said retrieved address to said requested            isochronous data.

With respect to non-time relevant data streams, and in particular,asynchronous data signals, streams or transfers, it is preferred, duringpractice of the method, or during use of the apparatus of the presentinvention, that the system be preferably capable of recognizingasynchronous transfers, when they are received. The data containedwithin the asynchronous transfer is then stored within the system for aperiod of time. Accordingly, the data that is received during aparticular time period may be stored and then transmitted in a followingtime period. Additionally, a further preferred embodiment of the presentinvention is that asynchronous transfers originating from a plurality ofsources may be stored, and retransmitted.

In the operation of a preferred embodiment of the current invention withrespect to a non-time relevant data stream, and an asynchronous datastream in particular, a host controller may issue a request to a devicefor the transfer of asynchronous data. The host controller must receivea response to corresponding to the issued request within 16 full-speedbit-times in the case of a full-speed bus (or 736 high-speed bit-timesin the case of a high-speed bus) according to the USB Specification. Therequest is received by the apparatus of the present invention, andretransmitted to the target device. On receipt of an initial request,the apparatus generates and transmits a synthetic data packet to thehost in order to satisfy the response time restriction. When therequested asynchronous transfer response is received by the apparatusfrom the target device, the asynchronous data is stored within theinternal memory of the apparatus. In the case where data flows from thedevice to the host, the apparatus generates and transmits a syntheticacknowledgment to the device on receipt of the response from the device.During a subsequent time period, the host controller will again issue arequest to the target device for the transfer of asynchronous data. Inaddition, however, the apparatus recognizes that it currently hasasynchronous data from the target device stored in its internal memory.The apparatus sends this data to the host controller within the amountof time specified by the USB Specification relevant to the currentrequest within the current time period. In the case where data flowsfrom the device to the host, the host generates an acknowledgment onreceipt of the requested data and the acknowledgment is absorbed by theapparatus. In this manner, the apparatus uses data collected in aprevious time period to satisfy the response time requirement of acurrent time period.

For interrupt data streams or transfers, a special case of asynchronousdata streams or transfers, the term “time period” preferably refers to asingle “frame” (1 ms) in the case of a full-speed bus or “microframe”(125 _(μ)s) in the case of a high-speed bus, as defined in the USBSpecification. However, the term “time period” may also apply to aportion of a frame or microframe, or a plurality of frames ormicroframes.

Furthermore, for interrupt data streams or transfers, subsequentrequests for the transfer of data generated by the host areretransmitted to the device by the apparatus.

For bulk or control data streams or transfers, two special cases ofasynchronous data streams or transfers, the term “time period” can referto a portion of a frame or microframe, a single frame or microframe, aplurality of frames or microframes, or the like. Said frame andmicroframe are as defined in the USB Specification.

Furthermore, for bulk or control data streams or transfers, subsequentrequests for the transfer of data generated by the host are absorbed bythe apparatus.

In the operation of a preferred embodiment of the current invention, ahigh-speed host controller may issue a PING control flow probe to ahigh-speed device, with control or bulk endpoints, inquiring about theavailability of space within the device for asynchronous data. Thecontrol flow probe is received by the apparatus of the presentinvention, and retransmitted to the target device. When the requestedresponse is received by the apparatus from the target device, theresponse is stored within the internal memory of the apparatus. During asubsequent time period, the host controller will again issue a PING tothe target device inquiring about the availability of space forasynchronous data. The apparatus will again retransmit this flow controlprobe to the target device. In addition, however, the apparatusrecognizes that it currently has a response from the target devicestored in its internal memory. The apparatus sends this response to thehost controller within the 736 high-speed bit-time margin relevant tothe current request within the time period. In this manner, theapparatus uses data collected in a previous time period to satisfy theresponse time requirement of a current time period.

In a preferred embodiment of either a time relevant or non-time relevantdata transmission, the extended distance exceeds 5 meters, morepreferably, exceeds 30 meters, and still more preferably, equals orexceeds 100 meters. In particular, the distance between the localexpander and the remote expander exceeds 5 meters, more preferably,exceeds 30 meters, and still more preferably, equals or exceeds 100meters.

As with the prior art, the method of the present invention can be usedin a system wherein said host controller is a PC, and said peripheraldevice is, for example, a camera, a mouse, a keyboard, a monitor or aspeaker or speakers. The “host controller” is preferably a PC, as hasbeen previously stated. However, the host controller may also be part ofa computer system, and in particular, part of a networked computersystem.

By utilizing the method and apparatus of the present invention, it ispossible to have transfer of time relevant data or non-time relevantdata, and isochronous data or asynchronous data in particular, overextended distances, and in particular over distances greater thanspecified in the USB Specification.

However, other features of the present invention, as well as otherobjects and advantages attendant thereto, are set forth in the followingdescription and the accompanying drawings in which like referencenumerals depict like elements.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, and various aspects thereof, will be described byreference to the attached drawings wherein:

FIG. 1 is a visual representation of a PC equipped with Extended RangeHub and USB Devices;

FIG. 2 is a schematic drawing of an embodiment of the invention designedto operate using fibre optic cabling as a signal distribution system;

FIG. 3 is a timing diagram showing isochronous transfers according tothe USB protocol;

FIG. 4 is a timing diagram showing isochronous transfers according tothe current invention;

FIG. 5 is a schematic drawing of one embodiment of a Local Expanderaccording to the invention;

FIG. 6 is a schematic drawing of one embodiment of a REX-FPGA accordingto the invention;

FIG. 7 is a sequence diagram showing an isochronous input transferbetween a full-speed host and a full-speed device according to theinvention;

FIG. 8 is a sequence diagram showing an isochronous output transferbetween a full-speed host and a full-speed device according to theinvention;

FIG. 9 is an algorithm for implementing isochronous input transfersbetween a full-speed host and a full-speed device, at the Local Expanderand Remote Expander, according to the invention;

FIG. 10 is an algorithm for implementing isochronous output transfersbetween a full-speed host and a full-speed device, at the Local Expanderand Remote Expander, according to the invention;

FIG. 11 is a sequence diagram showing an isochronous input transferbetween a high-speed host and a full-speed device according to theinvention;

FIG. 12 is a sequence diagram showing an isochronous output transferbetween a high-speed host and a full-speed device according to theinvention;

FIG. 13 is a sequence diagram showing an isochronous input transferbetween a high-speed host and a high-speed device according to theinvention;

FIG. 14 is a sequence diagram showing an isochronous output transferbetween a high-speed host and a high-speed device according to theinvention;

FIG. 15 is a sequence diagram showing a high bandwidth isochronous inputtransfer between a high-speed host and a high-speed device according tothe invention;

FIG. 16 is a sequence diagram showing a high bandwidth isochronousoutput transfer between a high-speed host and a high-speed deviceaccording to the invention;

FIG. 17 is a timing diagram showing interrupt transfers according to theUSB protocol;

FIG. 18 is a timing diagram showing interrupt transfers according to thecurrent invention;

FIG. 19 is a sequence diagram showing an interrupt input transferbetween a high-speed host and a low-speed device according to theinvention;

FIG. 20 is a sequence diagram showing an interrupt output transferbetween a high-speed host and a low-speed device according to theinvention;

FIG. 21 is a sequence diagram showing an interrupt input transferbetween a high-speed host and a high-speed device according to theinvention;

FIG. 22 is a sequence diagram showing an interrupt output transferbetween a high-speed host and a high-speed device according to theinvention;

FIG. 23 is a sequence diagram showing a high bandwidth interrupt inputtransfer between a high-speed host and a high-speed device according tothe invention;

FIG. 24 is a sequence diagram showing a high bandwidth interrupt outputtransfer between a high-speed host and a high-speed device according tothe invention;

FIG. 25 is a timing diagram showing control and bulk data transfersaccording to the USB protocol;

FIG. 26 is a timing diagram showing control and bulk data transfersaccording to the current invention;

FIG. 27 is a sequence diagram showing a control input transfer between ahigh-speed host and a low-speed device according to the invention;

FIG. 28 is a sequence diagram showing a control output transfer betweena high-speed host and a low-speed device according to the invention;

FIG. 29 is a sequence diagram showing a control input transfer between ahigh-speed host and a high-speed device according to the invention;

FIG. 30 is a sequence diagram showing a control output transfer betweena high-speed host and a high-speed device according to the invention;

FIG. 31 is a sequence diagram showing a bulk input transfer between ahigh-speed host and a full-speed device according to the invention;

FIG. 32 is a sequence diagram showing a bulk output transfer between ahigh-speed host and a full-speed device according to the invention;

FIG. 33 is a sequence diagram showing a PING protocol according to theinvention.

DESCRIPTION OF THE DRAWINGS

In the drawings, FIG. 1 shows a PC (1) connected to four standard USBDevices (3 a, 3 b, 3 c & 3 d). While the length of cable between the twohubs cannot normally exceed 5 meters according to the current USBSpecification, the PC (1) is also equipped with an apparatus accordingto the present invention, which is termed as an “Extended Range Hub”(7). The Extended Range Hub (7) is composed of two separate units, a“Local Expander” (4) or (LEX) and a “Remote Expander” (5) (or REX) whichare connected by cable (6). In one embodiment of the invention, units 4and 5 are separated by, for example, 200 meters of fibre optic cable (6)(although Category 5 UTP wiring or wireless transmission could also beused). This arrangement of devices is identical to the arrangementdescribed earlier in PCT application No. PCT/CA00/00157.

FIG. 2 illustrates a more schematic diagram of the arrangement describedin FIG. 1. The functions normally provided by a standard USB 2.0 Hub areprovided by two separate units (4 & 5) connected by a length of fibreoptic cable (6). In this representation, the REX unit (5) consists oftwo main components—the REX-FPGA (8) and a standard USB 2.0 Hub (9). TheREX-FPGA (8) component represents a Field Programmable Gate Array (FPGA)as well as other hardware components. The standard USB 2.0 Hub ishereinafter referred to as the REX-Hub(9). The REX-FPGA (8) is connectedto the LEX by a fibre optic cable (6), but might also be connected byUTP (Unshielded Twisted Pair) cable or wiring. The REX-Hub (9) isconnected to the REX-FPGA (8) within the REX unit (5) and said REX-Hub(9) would operate in the same manner whether connected to the REX-FPGA(8) or directly to the Host PC (1) (which might also be a standard USBhub). The REX-Hub (9) is connected to a plurality of USB devices. Inthis embodiment said plurality is chosen to be four, but it will beclear to those skilled in the art that other choices may be made withinthe scope of the invention.

Operation over extended distances is preferably achieved by placing saidLEX unit (4) close to said host PC (1), placing said REX unit (5) closeto said plurality of USB (3 a, 3 b, 3 c and/or 3 d) devices, andconnecting LEX unit (4) and REX unit (5) by the required extended lengthof fibre optic cabling (6).

FIG. 3 provides a prior art timing diagram showing isochronous transfersaccording to the USB protocol. The diagram is constructed from the pointof view of a USB Host Controller (1), normally included on a PCmotherboard (Host PC). The USB protocol divides time allocation on theshared bus into regular intervals. The duration in time of each intervalis represented by “t” in FIG. 3 and the duration of each interval willbe represented by “t” hereinafter. The start of each transactioninterval is identified on the diagram as I1, I2, I3, I4. For afull-speed host, the time allotted for each interval is 1 ms and suchintervals are hereinafter referred to as frames. For a high-speed host,the time allotted for each interval is 125 _(μ)s and such intervals arehereinafter referred to as microframes. Eight microframes are equivalentto one frame.

When a Host Controller (1) is engaged upon an isochronous transfer witha device (3), the Host Controller (1) issues regular requests for datatransfer to said device (3). These requests are identified as packetsR1, R2, and R3 (10, 12, & 14). Under the USB protocol, a USB device (3)must respond to the request from a full-speed host within 16 full-speedbit-times. In response to requests from a high-speed host, a USB devicemust respond within 736 high-speed bit-times. The responses are shown inthe diagram as packets Is1, Is2, and Is3 (11, 13, & 15). It is commonlyexpected that transfer Is1 (11) will be delivered in response to requestR1 (10) within the same interval, transfer Is2 (13) will be delivered inresponse to request R2 (12) within the same interval, and so on untilthe requests are terminated.

FIG. 4 provides a timing diagram showing isochronous transfers accordingto the present invention, which is, however, essentially identical tothe isochronous transfer described in PCT/CA00/00157 for full-speedtransfers. The diagram shows the progression of packets through thevarious subsystems comprising the invention. Timelines are presented forthe Host PC (1), Local Expander (4) and Remote Expander FPGA (8)components that are shown in FIG. 1.

An isochronous transfer is initiated from a Host.PC (1) by emitting arequest for input data R1 (20) to a particular USB address andend-point. Said request R1 (20) is received by the LEX (4) andretransmitted as R1 (25) over the external cabling to the REX-FPGA (8).Said retransmitted packet R1 (31) is received by the REX-FPGA andforwarded to the REX-Hub (9).

The target device generates an input data packet Is1 (32). According tothe USB protocol for low-speed and full-speed isochronous transfers, adevice with a detachable cable must generate a response within 6.5bit-times of the end of the corresponding request. For high-speedisochronous transfers, a device must generate a response within 192high-speed bit times. Said input data packet Is1 (32) is received by theREX-Hub (9) and the REX-FPGA subsystem (8) and retransmitted as Is1(26), over the external wiring, to the LEX. Said retransmitted responseIs1 (26) is not immediately forwarded to the Host PC, but is storedwithin the memory of the LEX subsystem.

The Host PC (1) notices that it did not receive a response to its inputdata request R1 (20) and retries the transaction by generating a furtherrequest R2 (21) to the same USB address and end-point. Upon receivingrequest R2 (21), the LEX subsystem retrieves response Is1 (26) from itsmemory buffers and forwards it to the Host PC as response Is1 (22).

Said second request R2 (21) is repeated as R2 (27) through the LEX andforwarded as R2 (33) to the device. The target device generates a secondresponse Is2 (34) which is retransmitted as Is2 (28) by the REX-FPGA tothe LEX. Response Is2 (28) is again stored within the memory of the LEXsubsystem, from where it is sent to the Host PC (1) as response Is2 (24)to a third request R3 (23). The process is repeated as necessary withrequest R3 (23), R3 (29) and R3 (35) and response Is3 (36) and Is3 (30).

FIG. 5 is a block diagram of an embodiment of a LEX (Local Expander) (4)according to the invention. In this embodiment, the USB 2.0 Transceiver(50) is connected to a USB host by conventional means, signified by thestandard USB signals D+ and D−.

Data signals from the USB host are received by Link Transceiver (50) andstored in the Dual FIFO (53). The Microprocessor (51) is alerted throughthe control channel from the transceiver that new data has arrived andis available in the FIFO. The Microprocessor (51) instructs the Router(54) to route the data according to predefined routing tables. TheRouter then copies the data from the Dual FIFO (53) to the appropriatedestination, either Dual FIFO (55) or Buffer (56). In the situationwhere the data is required to be absorbed, then the Router removes thedata from dual FIFO (53) and discards said data. When data is copied toDual FIFO (55), said data is transmitted over the extended range link byLink Transceiver (52) as D_(d) and D_(u).

If the treatment of the received data is not already defined by therouting tables, the Router (54) passes said received data to theMicroprocessor (51) for analysis. After inspecting said data, theMicroprocessor (51) updates the routing tables and returns control tothe Router (54).

A similar process occurs in the reverse direction when data is receivedfrom the extended range link by Link Transceiver (52). Said receiveddata is automatically copied to Dual FIFO (55) from where it istransferred to Buffer (56) or Dual FIFO (53) by Router (54) under thecontrol of Microprocessor (51). Data so transferred to Dual FIFO (53) istransmitted to the USB host by USB 2.0 Transceiver (50).

FIG. 6 is a block diagram of an embodiment of a REX-FPGA according tothe invention. The REX-FPGA (8) is connected to the extended range link(6) by Link Transceiver (60). The REX-FPGA is connected to REX-Hub (9)by USB 2.0 Transceiver (62) using conventional USB signals D+ and D−.

Data signals as D_(d) and D_(u), are received from extended range link(6) by Link Transceiver (60) and stored in Dual FIFO (63). TheMicroprocessor (61) is alerted through the control channel from thetransceiver that new data has arrived and is available in the FIFO. TheMicroprocessor instructs the Router (64) to route the data according topredefined routing tables. The Router then copies the data from the DualFIFO (63) to the appropriate destination, either Dual FIFO (65) orBuffer (66). If the data is required to be absorbed, then the Routerremoves the data from Dual FIFO (63) and discards said data. When datais copied to Dual FIFO (65), said data is transmitted to the Rex-Hub byUSB 2.0 Transceiver (62)

If the treatment of the received data is not already defined by therouting tables, the Router passes said received data to theMicroprocessor for analysis. After inspecting said data, theMicroprocessor updates the routing tables and returns control to theRouter.

A similar process occurs in the reverse direction when data is receivedfrom the Rex-Hub by USB 2.0 Transceiver (62). Said received data isautomatically copied to Dual FIFO (65) from where it is transferred toBuffer (66) or Dual FIFO (63) by Router (64) under the control ofMicroprocessor (61). Data so transferred to Dual FIFO (63) istransmitted to the extended range link by Link Transceiver (60).

FIG. 7 provides a sequence diagram showing an isochronous inputtransfer, between a full-speed host and a full-speed device. In Frame 1,a request for input data is transmitted from the Host control logic(100) and said request is received by the LEX subsystem as an IN packet.The control logic (101) within the LEX subsystem forwards the IN packetto the REX-FPGA subsystem. The control logic (102) within the REX-FPGAsubsystem forwards the IN packet to the REX-Hub. The control logic (103)within the REX-Hub forwards the IN packet to the Device.

The control logic (104) within the device assembles the requestedisochronous data and transmits said data as a Result packet to theREX-Hub. The control logic (103) within the REX-Hub forwards the Resultpacket to the REX-FPGA subsystem. The control logic (102) within theREX-FPGA subsystem forwards the Result packet to the LEX subsystem. Thecontrol logic (101) in the LEX subsystem stores the Result packet in itsbuffer memory.

In Frame 2, the control logic (105) within the Host recognizes that ithas not received a response to its previous request for input data andit automatically retries the transaction by generating a further requestaddressed to the same USB function as in Frame 1. Said further requestis transmitted to the LEX subsystem as a second IN packet. On receipt ofthe second IN packet, the control logic (106) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further IN packet and transmits said Resultpacket to the host Said control logic (106) also forwards the further INpacket to the REX-FPGA subsystem. The control logic (107) within theREX-FPGA subsystem forwards said IN packet to the REX-Hub. The controllogic (108) within the REX-Hub forwards the IN packet to the Device.

The control logic (109) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (108) within the REX-Hub forwards the Result packet to theREX-FPGA subsystem. The control logic (107) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (106) in the LEX subsystem stores the Result packet in its buffermemory.

The above-described process is repeated for subsequent frames by thedistributed control logic (e.g. 105, 106, 107, 108, 109).

FIG. 8 provides a sequence diagram showing an isochronous outputtransfer, between a full-speed host and a full-speed device. In Frame 1,the control logic (100) within the Host generates a notification ofoutput data, addressed to a particular USB function. Said notificationis transmitted to the LEX subsystem as an OUT packet. The control logic(101) within the LEX subsystem forwards said OUT packet to the REX-FPGAsubsystem. The control logic (102) within the REX-FPGA subsystemforwards said OUT packet to the REX-Hub. The control logic (103) withinthe REX-Hub forwards said OUT packet to the Device. The information isreceived by the control logic within the device.

The control logic (100) within the Host assembles the notifiedisochronous data and transmits it as a Data0 packet to the LEXsubsystem. The control logic (101) within the LEX subsystem forwards theData0 packet to the REX-FPGA subsystem. The control logic (102) withinthe REX-FPGA subsystem forwards said Data0 packet to the REX-Hub. Thecontrol logic (103) within the REX-Hub forwards said Data0 packet to thedevice. The information is received by the control logic (104) withinthe device.

The above-described process is repeated for subsequent frames by thedistributed control logic (e.g. 100, 101, 102, 103, 104).

FIG. 9 provides an algorithm for implementing isochronous inputtransfers, between a full-speed host and a full-speed device, at theLocal Expander and Remote Expander. Said algorithm is implemented inhardware by the LEX and REX-FPGA Controllers. According to theinvention, the algorithm of LEX controller is required to implement theprocessing functions represented by processing blocks (101) and (106) ofFIG. 7. The algorithm of REX controller is required to implement theprocessing functions represented by processing blocks (102) and (107) ofFIG. 7.

According to said algorithm programmed in the LEX controller, if thereceived packet is of type IN then an identical packet is transmitted tothe REX-FPGA controller. The LEX controller then examines its buffermemory to determine whether a stored Result packet from the deviceaddressed by the IN request is already present in memory. If no suchstored Result packet is present in memory, the system then becomes idle.If said stored Result packet is present in memory, the system retrievessaid stored packet from memory and sends said packet to the host as apacket of type Result. If the received packet is of type Result then thepacket is stored in the buffer memory.

According to said algorithm programmed in the REX-FPGA controller, ifthe received packet is of type IN then an identical packet is forwardedto the REX hub. If the received packet is of type Result, then thepacket is transmitted to the LEX controller.

FIG. 10 provides an algorithm for implementing isochronous outputtransfers, between a full-speed host and a full-speed device, at theLocal Expander and the Remote Expander. According to the invention, thealgorithm of the LEX controller is required to implement the processingfunctions represented by processing block (101) of FIG. 8. The algorithmof the REX-FPGA controller is required to implement the processingfunctions represented by the processing block (102) of FIG. 8.

According to the said algorithm, if the received packet at the LEXcontroller is of type OUT or DATA0, then said packet is forwarded to theREX-FPGA controller. If the received packet at the REX-FPGA controlleris of type OUT or DATA0 then said packet is transmitted to the REX hub.

The production of the algorithms shown In FIGS. 9 and 10 are consideredto be easily prepared by the skilled artisan once the sequence diagramis understood. Accordingly, the algorithms for the remaining sequencedrawings will not be produced.

FIG. 11 provides a sequence diagram showing an isochronous inputtransfer, between a high-speed host and a full-speed device. In the lastmicroframe of the previous frame, (Y-1)₇, a start split-transaction anda request for input data are transmitted from the Host control logic(120). Said start split-transaction and the request for input data arereceived by the LEX subsystem as a SSPLIT packet and an IN packet(SSPLIT/IN packets). The control logic (121) within the LEX subsystemforwards the SSPLIT/IN packets to the REX-FPGA subsystem. The controllogic (122) within the REX-FPGA subsystem forwards said SSPLIT/INpackets to the REX-Hub.

In the first microframe of the current frame, Y₀, the control logic(128) within the REX-Hub absorbs said SSPLIT packet and forwards said INpacket to the Device. The control logic (129) within the deviceassembles the requested isochronous data packet and transmits the sameto the REX-Hub as a continuous stream of data. The size of saidisochronous data packet may range from 0 to 1023 bytes, as defined bythe USB Specification. The control logic (133) within the REX-Hub storesup to the first 188 bytes of data as a Result packet in its buffermemory.

In the next microframe, Y₁, the control logic (131) within the LEXsubsystem receives the complete split-transaction and the request forinput data from the Host control logic (130) as a CSPLIT packet and anIN packet. With no Result packet stored in its buffer memory, thecontrol logic (131) within the LEX subsystem then generates a syntheticdata packet and transmits it as a NYET packet to the Host PC in responseto the request for input data. The control logic (131) within the LEXsubsystem forwards said CSPLIT/IN packets to the REX-FPGA subsystem. Thecontrol logic (132) within the REX-FPGA subsystem forwards saidCSPLIT/IN packets to the REX-Hub. On receipt of said CSPLIT/IN packets,the control logic (133) within the REX-Hub recognizes that it containsin its buffer memory the first portion of the data packet from thedevice. Said control logic retrieves said stored packet and forwards thesame to the REX-FPGA as a Result packet. Said control logic (133) alsoabsorbs said CSPLIT/IN packets. The control logic (132) within theREX-FPGA subsystem forwards the Result packet to the LEX subsystem. Thecontrol logic (131) in the LEX subsystem stores the Result packet in itsbuffer memory.

The control logic (138) within the REX-Hub stores up to the next 188bytes of the remaining data from the device as a Result packet in itsbuffer memory.

In the subsequent microframe, Y₂, the control logic (136) within the LEXsubsystem receives the subsequent CSPLIT/IN packets from the controllogic (135) within the Host. The control logic (136) within the LEXsubsystem forwards the stored Result packet, received in the previousmicroframe, to the Host and forwards said CSPLIT/IN packets to theREX-FPGA subsystem. The control logic (137) within the REX-FPGAsubsystem forwards the CSPLIT/IN packets to the REX-Hub. On receipt ofsaid CSPLIT/IN packets, the control logic (138) within the REX-Hubrecognizes that it contains the second portion of the data packet fromthe device stored in its buffer memory. Said control logic retrievessaid stored packet and forwards the same to the REX-FPGA as a Resultpacket. Said control logic (138) also recognizes that said CSPLIT/INpackets are merely a repetition of the previous CSPLIT/IN packet andabsorbs said packets. The control logic (138) within the REX-Hubforwards the Result packet to the REX-FPGA subsystem. The control logic(137) within the REX-FPGA subsystem forwards the Result packet to theLEX subsystem. The control logic (136) in the LEX subsystems stores theResult packet in its buffer memory.

The above-described process is repeated until all the data generated bythe device is transmitted to the host by the distributed control logic(e.g. 135, 136, 137, 138, 139). The process described by the distributedcontrol logic (120) to (139) is also repeated for subsequent frames.

In FIG. 11, a dotted line is also shown between the device and theREX-Hub. This dotted line is used to represent the total data flow fromthe device to the REX-Hub, even though in this case, the REX-Hubinterprets the receipt of data as being three data transmissions. Insubsequent figures, this dotted line will be used to represent the totaldata transmission even though the various devices or hubs may treat thetransmission as a series of data transmissions.

FIG. 12 provides a sequence diagram showing an isochronous outputtransfer, between a high-speed host and a full-speed device. In the lastmicroframe of the previous frame, Microframe (Y-1)₇, the control logic(120) within the Host generates a start split-transaction (begin), anotification of output data, and a data packet to the LEX subsystem.Said data packet may contain a maximum of 188 bytes of data. Said startsplit-transaction, notification of output data, and data packet aretransmitted to the LEX subsystem as an SSPLIT-begin packet, an OUTpacket, and a DATA0 packet, respectively. The control logic (121) withinthe LEX subsystem forwards said SSPLIT-begin/OUT/DATA0 packets to theREX-FGPA subsystem. The control logic (122) within the REX-FPGAsubsystem forwards said SSPLIT-begin/OUT/DATA0 packets to the REX-Hub.On receipt of said SSPLIT-begin/OUT/DATA0 packets, the control logic(123) within the REX-Hub absorbs said SSPLIT-begin/OUT packets andstores said DATA0 packet in its buffer memory.

In the first microframe of the current frame, Microframe Y₀, the controllogic (128) within the REX-Hub generates a notification of output dataand forwards the same to the Device as an OUT packet. At the same time,the control logic (125) within the host generates a startsplit-transaction (mid), a notification of output data, and a datapacket and transmits the same to the LEX subsystem asSSPLIT-mid/OUT/DATA0 packets. Said data packet may contain a maximum of188 bytes of data. The control logic (126) within the LEX subsystemforwards said SSPLIT-mid/OUT/DATA0 packets to the REX-FPGA subsystem.The control logic (127) within the REX-FPGA subsystem forwards saidSSPLIT-mid/OUT/DATA0 packets to the REX-Hub. On receipt of saidSSPLIT-mid/OUT/DATA0 packets, the control logic (128) within the REX-Hubbegins forwarding the stored data packet received in the previousmicroframe to the device. Said control logic also absorbs saidSSPLIT-mid/OUT packets and stores the further data packet in its buffermemory.

In the subsequent microframe, Microframe Y₁, the control logic (130)within the host generates a start split-transaction, a notification ofoutput data, and a data packet and transmits the same to the LEXsubsystem as SSPLIT-mid/OUT/DATA0 packets. Said data packet may containa maximum of 188 bytes of data. The control logic (131) within the LEXsubsystem forwards said SSPLIT-mid/OUT/DATA0 packets to the REX-FPGAsubsystem. The control logic (132) within the REX-FPGA subsystemforwards said SSPLIT-mid/OUT/DATA0 packets to the REX-Hub. On receipt ofsaid SSPLIT-mid/OUT/DATA0 packets, the control logic (133) within theREX-Hub begins forwarding the stored data packet received in theprevious microframe to the device. The control logic (134) within thedevice receives the first byte of said stored data packet immediatelyafter receiving the last byte of the data packet sent from the previousframe. The control logic within the REX-Hub transmits data packets tothe device in such a manner that the device receives a continuous datastream. The control logic (133) within the REX-Hub also absorbs saidSSPLIT-mid/OUT packets and stores said further data packet.

The above-described process is repeated until the host controllertransmits the last output data packet by the distributed control logic(e.g. 130, 131,132, 133, 134). The process described by the distributedcontrol logic (120) to (134) is also repeated for subsequent frames.

FIG. 13 provides a sequence diagram showing an isochronous inputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, a request for input data is transmitted from the Hostcontrol logic (150) and said request is received by the LEX subsystem asan IN packet. The control logic (151) within the LEX subsystem forwardsthe IN packet to the REX-FPGA subsystem. The control logic (152) withinthe REX-FPGA subsystem forwards said IN packet to the REX-Hub. Thecontrol logic (153) within the REX-Hub forwards said IN packet to theDevice.

The control logic (154) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (153) within the REX-Hub forwards the Result packet to theREX-FPGA subsystem. The control logic (152) within the REX-FPGAsubsystem forwards the Result packet to the LEX subsystem. The controllogic (151) in the LEX subsystem stores the Result packet in its buffermemory.

In Microframe Y₁, the control logic (155) within the Host recognizesthat it has not received a response to its previous request for inputdata and it automatically retries the transaction by generating afurther request addressed to the same USB function as in Microframe Y₀.Said further request is transmitted to the LEX subsystem as a second INpacket. On receipt of the second IN packet, the control logic (156)within the LEX subsystem recognizes that it has a Result packet storedin memory from the same function identified by the further IN packet andtransmits said packet to the host. Said control logic (156) alsoforwards the further IN packet to the REX-FPGA subsystem. The controllogic (157) within the REX-FPGA subsystem forwards said IN packet to theREX-Hub. The control logic (158) within the REX-Hub forwards said INpacket to the Device.

The control logic (159) within the device assembles the requestedisochronous data and transmits it as a Result packet to the REX-Hub. Thecontrol logic (158) within the REX-Hub forwards said Result packet tothe REX-FPGA subsystem. The control logic (157) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (156) in the LEX subsystem stores said Result packet in its buffermemory.

The above-described process is repeated for subsequent microframes bythe distributed control logic (e.g. 155,156, 157, 158, 159).

FIG. 14 provides a sequence diagram showing an isochronous outputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (150) within the Host generates anotification of output data, addressed to a particular USB function.Said notification is transmitted to the LEX subsystem as an OUT packet.The control logic (151) within the LEX subsystem forwards said OUTpacket to the REX-FPGA subsystem. The control logic (152) within theREX-FPGA subsystem forwards said OUT packet to the REX-Hub. The controllogic (153) within the REX-Hub forwards said OUT packet to the Device.The information is received by the control logic within the device.

The control logic (150) within the Host assembles the notifiedisochronous data and transmits it as a DATA0 packet to the LEXsubsystem. The control logic (151) within the LEX subsystem forwardssaid DATA0 packet to the REX-FPGA subsystem. The control logic (152)within the REX-FPGA subsystem forwards said DATA0 packet to the REX-Hub.The control logic (153) within the REX-Hub forwards said DATA0 packet tothe device. The information is received by the control logic (154)within the device.

The above-described process is repeated for subsequent microframes bythe distributed control logic (e.g. 150, 151, 152, 153, 154).

FIG. 15 provides a sequence diagram showing a high-bandwidth isochronousinput transfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (170) in the Host PC generates arequest for input data. Said request for input data is transmitted tothe LEX subsystem as an IN packet. The control logic (171) within theLEX subsystem generates a synthetic data packet and transmits it as aNULL packet to the Host in response to the input data request. Thecontrol logic (171) within the LEX subsystem forwards the IN packet tothe REX-FPGA subsystem. The control logic (172) within the REX-FPGAsubsystem forwards said IN packet to the REX-Hub. The control logic(173) within the REX-Hub forwards said IN packet to the Device.

The control logic (174) within the device assembles the requestedisochronous data and transmits it as a Result_1_1 packet to the REX-Hub.The control logic (173) within the REX-Hub forwards the Result_1_1packet to the REX-FPGA subsystem. The control logic (172) within theREX-FPGA subsystem forwards the Result_1_1 packet to the LEX subsystem.The control logic (171) in the LEX subsystem stores the Result_1_1packet in its buffer memory.

On receipt of the first NULL packet generated by the LEX subsystem, thecontrol logic (170) within the Host generates a second request for inputdata within the same microframe, Y₀. Said request for input data istransmitted to the LEX subsystem as an IN packet. The control logic(171) within the LEX subsystem generates a second synthetic data packetand transmits it as a NULL packet to the Host. The second IN packet isforwarded to the device in the same manner as the first IN packet.

On receipt of the second IN packet, the control logic (174) within thedevice assembles the requested isochronous data and transmits it as aResult_1_2 packet to the REX-Hub. The Result_1_2 packet is transmittedto the LEX subsystem in the same manner as the Result_1_1 packet and itis also stored in the buffer memory of the LEX subsystem.

On receipt of the second NULL packet generated by the LEX subsystem, thecontrol logic (170) within the Host generates a third request for inputdata within the same microframe, Y₀. Said request for input data istransmitted to the LEX subsystem as an IN packet. The control logic(171) within the LEX subsystem generates a third synthetic data packetand transmits it as a NULL packet to the Host. The third IN packet isforwarded to the device in the same manner as the first and second INpacket.

On receipt of the third IN packet, the control logic (174) within thedevice assembles the requested isochronous data and transmits it as aResult_1_3 packet to the REX-Hub. The Result_1_3 packet is transmittedto the LEX subsystem in the same manner as the Result_1_1 and Result_1_2packets and it is also stored in the buffer memory of the LEX subsystem.

In Microframe Y₁, the control logic (175) within the Host generates arequest for input data and transmits said request as an IN packet to theLEX subsystem. The control logic (176) within the LEX subsystem forwardsthe first stored result packet, Result_1_1, to the Host in response tothe input data request. The control logic (176) within the LEX subsystemforwards said IN packet to the REX-FPGA subsystem. The control logic(177) within the REX-FPGA subsystem forwards said IN packet to theREX-Hub. The control logic (178) within the REX-Hub forwards said INpacket to the Device.

On receipt of said IN packet, the control logic (179) within the deviceassembles the requested isochronous data and transmits it as aResult_2_1 packet to the REX-Hub. The control logic (178) within theREX-Hub forwards the Result_2_1 packet to the REX-FPGA subsystem. Thecontrol logic (177) within the REX-FPGA subsystem forwards theResult_2_1 packet to the LEX subsystem. The control logic (176) withinthe LEX subsystem stores the Result_2_1 packet in its buffer memory.

Within the same microframe, Y₁, the control logic (175) within the Hostgenerates a second request for input data and transmits said request asan IN packet to the LEX subsystem. The control logic (176) within theLEX subsystem forwards the second stored result packet, Result_1_2, tothe Host In response to the input data request. Said IN packet isforwarded to the device in the same manner as the previous IN packet.

On receipt of the second IN packet, the control logic (179) within thedevice assembles the requested isochronous data and transmits it as aResult_2_2 packet to the REX-Hub. The Result_2_2 packet is transmittedto the LEX subsystem in the same manner as the Result_2_1 packet and itis stored in the buffer memory of the LEX subsystem.

Within the same microframe, Y₁, the control logic (175) within the Hostgenerates a third request for input data and transmits said request asan IN packet to the LEX subsystem. The control logic (176) within theLEX subsystem forwards the third stored result packet, Result_1_3, tothe Host in response to the input data request. Said IN packet isforwarded to the device in the same manner as the previous IN packet.

On receipt of the third IN packet, the control logic (179) within thedevice assembles the requested isochronous data and transmits it as aResult_2_3 packet to the REX-Hub. The Result_2_3 packet is transmittedto the LEX subsystem in the same manner as the Result_2_1 and Result_2_2and it is stored in the buffer memory of the LEX subsystem.

The above-described process is repeated for subsequent microframes bythe distributed control logic (e.g. 175, 176, 177, 178, 179).

FIG. 16 provides a sequence diagram showing a high-bandwidth isochronousoutput transfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (170) within the Host generates anotification of output data addressed to a particular USB function. Saidnotification is transmitted to the LEX subsystem as an OUT packet. Thecontrol logic (171) within the LEX subsystem forwards said OUT packet tothe REX-FPGA subsystem. The control logic (172) within the REX-FPGAsubsystem forwards said OUT packet to the REX-Hub. The control logic(173) within the REX-Hub forwards said OUT packet to the Device. Theinformation is received by the control logic within the device.

The control logic (170) within the Host assembles the notifiedisochronous data and transmits it as an MData packet to the LEXsubsystem. The control logic (171) within the LEX subsystem forwardssaid MData packet to the REX-FPGA subsystem. The control logic (172)within the REX-FPGA subsystem forwards said MDATA packet to the REX-Hub.The control logic (173) within the REX-Hub forwards said MDATA packet tothe device. The information is received by the control logic (174)within the device.

Within the same microframe, Y₀, the control logic (170) within the Hostgenerates a second notification of output data. Said notification istransmitted to the LEX subsystem as an OUT packet and is transmitted tothe device in the same manner as the previous OUT packet. The controllogic (170) within the Host then assembles the notified isochronous dataand transmits it as a second MDATA packet to the LEX subsystem. SaidMDATA packet is transmitted to the device in the same manner as theprevious MDATA packet.

In the same microframe, Y₀, the control logic (170) within the Hostgenerates a third notification of output data. Said notification istransmitted to the LEX subsystem as an OUT packet and is transmitted tothe device in the same manner as the previous OUT packet. The controllogic (170) within the Host then assembles the notified isochronous dataand transmits the same as a DATA0 packet to the LEX subsystem. Thecontrol logic (171) within the LEX subsystem forwards said DATA0 packetto the REX-FPGA subsystem. The control logic (172) within the REX-FPGAsubsystem forwards said DATA0 packet to the REX-Hub. The control logic(173) within the REX-Hub forwards said DATA0 packet to the device. Theinformation is received by the control logic (174) within the device.

FIG. 17 provides a simplified timing diagram showing interrupttransfers, a special case of asynchronous transfers, according to theprior art USB protocol. The diagram is constructed from the point ofview of a USB Host Controller, normally included on a PC motherboard(Host PC). The USB protocol divides time allocation on the shared businto regular intervals. The start of each interval is again identifiedon the diagram as I1, I2, I3, I4. For a full-speed host, each intervalis 1 ms in duration and Is again referred to as a frame. For ahigh-speed host, each interval is 125 _(μ)s in duration and is referredto as a microframe.

When a Host Controller is engaged upon an interrupt transfer with adevice, the Host Controller issues regular requests for data transfer tosaid device. These requests are identified as packets R1, R2, and R3(10, 13, & 17). Under the USB protocol, a USB device must respond to therequest from a full-speed host within 16 full-speed bit-times. Inresponse to requests from a high-speed host, a USB device must respondwithin 736 high-speed bit-times. The responses are shown in the diagramas packets In1, In2, and In3 (11, 14, & 18). On receipt of a responsepacket, the Host Controller also emits an acknowledgement and theseacknowledgements are identified as packets K1, K2, K3 (12, 15, & 19). Itis commonly expected that transfer In1 (11) will be delivered inresponse to request R1 (10) and acknowledgement K1 (12) will be emittedon receipt of In1 (11) within the same interval, transfer In2 (14) willbe delivered in response to request R2 (13) and acknowledgement K2 (15)will be emitted on receipt of In2 (14) within the same interval, and soon until the requests are terminated.

FIG. 18 provides a simplified timing diagram showing interrupttransfers, a special case of asynchronous transfers, which isessentially identical to the system described in PCT/CA00/00157, forfull-speed hosts and/or devices. The diagram shows the progression ofpackets through the various subsystems comprising the invention. Timelines are presented for the Host PC (1), Local Expander (4) and RemoteExpander FPGA (8) subsystems as shown in FIG. 2.

An interrupt transfer is initiated from a Host PC (1) by emitting arequest for input data R1 (20) to a particular USB address andend-point. Said request R1 (20) is received by the LEX and retransmittedas R1 (25) over the external cabling to the REX-FPGA (8). Saidretransmitted packet R1 (25) is received by the REX-FPGA and forwardedas R1 (32) to the REX-Hub (9). A synthetic negative acknowledgementpacket is generated by the LEX (4) and transmitted as N1 (26) to thehost.

The target device generates an input data packet In1 (33). According tothe USB protocol for low-speed and full-speed isochronous transfers, adevice with a detachable cable must generate a response within 6.5full-speed bit-times of the end of the corresponding request. Forhigh-speed isochronous transfers, a device must generate a responsewithin 192 high-speed bit times. Said input data packet In1 (33) isreceived by the REX-Hub (9) and the REX-FPGA (8) subsystem andretransmitted as In1 (27) over the external wiring to the LEX (4). Saidretransmitted response In1 (27) is not immediately forwarded to the HostPC (1), but is stored within the memory of the LEX subsystem (4). Asynthetic acknowledgement packet K1 (34) is generated by the REX-FGPAsubsystem (8) and transmitted as K1 (34) to the REX-Hub (9).

The Host PC (1) notices that it did not receive data in response to itsrequest R1 (20), and retries the transaction by generating a furtherrequest R2 (22) to the same USB address and end-point. Upon receivingrequest R2 (28), the LEX subsystem retrieves response In1 (27) from itsmemory buffers and forwards it to the Host PC (1) as response In1 (29).Said response is received by the Host as response In1 (23). Uponreceiving said response In1 (23), the Host generates an acknowledgementpacket and transmits the packet as packet K1 (24) to the LEX subsystem(4). Said acknowledgement packet K1 (30) is received and absorbed byLEX.

Said second request R2 (22) is repeated as R2 (28) through the LEX andforwarded as R2 (35) to the device. The target device generates a secondresponse In2 (36) which is transmitted as In2 (31) to the LEX. Saidretransmitted response In2 (31) is stored in the memory of the LEXsubsystem. A synthetic acknowledgement packet is generated by theREX-FPGA subsystem and transmitted to the REX-Hub. The protocol sequenceis repeated as necessary.

FIG. 19 provides a sequence diagram showing an interrupt input transfer,between a high-speed host and a full-speed or low-speed device. In themicroframe before the current frame, Microframe (Y-1)₇, the controllogic (240) within the Host generates a start split-transaction followedby a request for input data, addressed to a particular USB function.Said split-transaction and request are transmitted to the LEX subsystemas an SSPLIT packet and an IN packet (SSPLIT/IN packets). The controllogic (241) within the LEX subsystem forwards the SSPLIT/IN packets tothe REX-FPGA subsystem. The control logic (242) within the REX-FPGAsubsystem forwards said SSPLIT/IN packets to the REX-Hub. The controllogic (243) within the REX-Hub absorbs said SSPLIT packet. In the firstmicroframe of the current frame, Microframe Y₀, the control logic (248)within the REX-Hub forwards said IN packet to the Device. The controllogic (249) within the device assembles the requested interrupt data andtransmits the same as a Result packet to the REX-Hub.

In the next microframe, Microframe Y₁, the control logic (250) in theHost recognizes that it has not received a response to its previousrequest for input data. Said control logic automatically retries thetransaction by generating a complete split-transaction followed by afurther request addressed to the same USB function as in Microframe(Y-1)₇. Said split-transaction and further request are transmitted tothe LEX subsystem as a CSPLIT packet and an IN packet (CSPLIT/INpackets). On receipt of said CSPLIT/IN packets, the control logic (251)within the LEX subsystem recognizes the lack of data that corresponds tothe Input request in its buffer memory. Said control logic (251) thengenerates a NYET packet to the Host. Said NYET packet warns the Hostthat the LEX subsystem has not yet received a response from the deviceand enables said Host to progress to the next transaction. Said controllogic (251) also forwards the CSPLIT/IN packets to the REX-FPGAsubsystem. The control logic (252) within the REX-FPGA subsystemforwards said CSPLIT/IN packets to the REX-Hub.

The control logic (253) within the REX-Hub receives the Result packetfrom the device and forwards said Result packet to the REX-FPGAsubsystem. On receipt of said Result packet, the control logic (252)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket which is transmitted as an ACK packet to the REX-Hub. The controllogic (253) within the REX-Hub forwards said ACK packet to the Device.The control logic (252) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem and the control logic (251) withinthe LEX subsystem stores said result packet in its buffer memory.

In the next microframe, Microframe Y₂, the control logic (255) in theHost recognizes that it has not received the requested data andautomatically retries the transaction by generating a further completesplit-transaction and a further request addressed to the same USBfunction as in Microframe Y₁. The complete split-transaction and requestfor input data are transmitted to the LEX subsystem as CSPLIT/INpackets. On receipt of the CSPLIT/IN packets, the control logic (256)within the LEX subsystem recognizes that it has a Result packet storedin memory from the same function identified by the further CSPLIT/INpackets. Said control logic retrieves said stored Result packet frommemory and transmits said stored packet to the Host. Said control logicalso recognizes that said CSPLIT/IN packets are merely a repetition ofthe previous CSPLIT/IN packets and absorbs said packets. When thecontrol logic (255) of the Host receives the requested Result packetfrom the LEX, said control logic generates an ACK packet to acknowledgea successful transmission. Upon receipt of the ACK packet from the host,the control logic (256) within the LEX subsystem absorbs said ACKpacket.

FIG. 20 provides a sequence diagram showing an interrupt outputtransfer, between a high-speed host and a full speed or low-speeddevice. In Microframe Y₀, the control logic (240) generates a startsplit-transaction, a notification of output data, and output data,addressed to a particular USB function. Said start split-transaction,notification of output data, and output data are transmitted to the LEXsubsystem as an SSPLIT packet, an OUT packet, and a DATAX packet,respectively. Said DATAX packet represents either a DATA0 packet or aDATA1 packet. The control logic (241) within the LEX subsystem forwardssaid SSPLIT/OUT/DATAX packets to the REX-FPGA subsystem. The controllogic (242) within the REX-FPGA subsystem forwards said SSPLIT/OUT/DATAXpackets to the REX-Hub.

In Microframe Y₁, the control logic (248) within the REX-Hub forwardsthe OUT packet and DATAX packet to the device. The information isreceived by the control logic (249) within the device. On receipt ofsaid DATAX packet, the control logic (249) within the device generatesan acknowledgement and transmits the same to the REX-Hub as a Resultpacket. The control logic (248) within the REX-Hub stores said Resultpacket in its buffer memory.

In Microframe Y₂, the control logic (250) within the Host generates acomplete split-transaction followed by a notification of output data,addressed to the same USB function as in Microframe Y₀. Said completesplit transaction and notification of output data are transmitted to theLEX subsystem as a CSPLIT packet and an OUT packet (CSPLIT/OUT packets).On receipt of said CSPLIT/OUT packets, the control logic (251) withinthe LEX subsystem recognizes the lack of data that corresponds to theCSPLIT/OUT packets in its buffer memory. Said control logic (251) thengenerates a NYET packet to the Host. Said NYET packet warns the Hostthat the LEX subsystem has not yet received a response from the deviceand enables said Host to progress to the next transaction. The controllogic (251) within the LEX subsystem forwards said CSPLIT/OUT packets tothe REX-FPGA subsystem. The control logic (252) within the REX-FPGAsubsystem forwards said CSPLIT/OUT packets to the REX-Hub.

On receipt of the CSPLIT/OUT packets, the control logic (253) within theREX-Hub recognizes that it has a Result packet stored in memory from thefunction identified by the SSPLIT/OUT/DATAX packets from Microframe Y₀.Said control logic retrieves said stored Result packet from memory andtransmits the same to the REX-FPGA subsystem. The control logic (252)within the REX-FPGA subsystem forwards said Result packet to the LEXsubsystem. The control logic (251) within the LEX subsystem stores saidResult packet in its buffer memory.

In Microframe Y₃, the control logic (255) within the host recognizesthat it has not yet received an acknowledgement from the device. Saidcontrol logic generates a further complete split-transaction and afurther notification of output data, addressed to the same USB functionas in the previous microframe. Said complete split-transaction andnotification of output data are transmitted to the LEX subsystem asfurther CSPLIT/OUT packets. On receipt of the CSPLIT/OUT packets, thecontrol logic (256) within the LEX subsystem recognizes that it has aResult packet stored in the memory from the function identified by thefurther CSPLIT/OUT packets. Said control logic retrieves said storedResult packet from memory and transmits the same to the Host. Saidcontrol logic also recognizes that said CSPLIT/OUT packets are merely arepetition of the previous CSPLIT/OUT packets and absorbs said packets.

FIG. 21 provides a sequence diagram showing an interrupt input transfer,between a high-speed host and a high-speed device. In Microframe Y₀, thecontrol logic (260) within the Host generates a request for input data,addressed to a particular USB function. Said request is transmitted tothe LEX subsystem as an IN packet. On receipt of said IN packet, thecontrol logic (261) within the LEX subsystem recognizes the lack of datathat corresponds to the input request in its buffer memory. Said controllogic (261) then generates a synthetic negative acknowledgement packetand transmits the same as a NAK packet to the Host. Said NAK packetwarns the Host that it will not receive a response to its request andenables said Host to progress to the next transaction. The control logic(261) within the LEX subsystem forwards the IN packet to the REX-FPGAsubsystem. The control logic (262) within the REX-FPGA subsystemforwards said IN packet to the REX-Hub. The control logic (263) withinthe REX-Hub forwards said request for input data as an IN packet to theDevice. The control logic (264) within the device assembles therequested interrupt data and transmits the same as a Result packet tothe REX-Hub. The control logic (263) within the REX-Hub forwards theResult packet to the REX-FPGA subsystem. On receipt of said Resultpacket, the control logic (262) within the REX-FPGA subsystem generatesa synthetic acknowledgement packet that is transmitted as an ACK packetto the REX-Hub.

The control logic (263) within the REX-Hub forwards said ACK packet tothe Device. The control logic (262) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem and the control logic(261) within the LEX subsystem stores said result packet in its buffermemory.

In Microframe Y₁, the control logic (265) within the Host recognizesthat it has not received the requested data and automatically retriesthe transaction by generating a further request addressed to the sameUSB function as in Microframe Y₀. Said further request is transmitted tothe LEX subsystem as a second IN packet. On receipt of the second INpacket, the control logic (266) within the LEX subsystem recognizes thatit has a Result packet stored in memory from the same functionidentified by the further IN packet. Said control logic retrieves saidstored Result packet from memory and transmits the same packet to theHost When the control logic (265) of the Host receives the requestedResult packet from the LEX, said control logic generates an ACK packetto acknowledge a successful transmission. Upon receipt of the ACK packetfrom the host, the control logic (266) within the LEX subsystem absorbssaid packet. Said control logic (266) forwards the further IN packet tothe REX-FPGA subsystem. The control logic (267) within the REX-FPGAforwards said IN packet to the REX-Hub. The control logic (268) withinthe REX-Hub forwards said request for input data as an IN packet to theDevice.

The control logic (269) within the device assembles the requestedinterrupt data and transmits the same as a Result packet to the REX-Hub.The control logic (268) within the REX-Hub forwards the Result packet tothe FPGA subsystem. On receipt of said Result packet, the control logic(267) within the REX-FPGA subsystem generates a syntheticacknowledgement packet that is transmitted as an ACK packet to theREX-Hub. The control logic (268) within the REX-Hub forwards said ACKpacket to the Device. The control logic (267) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (266) within the LEX subsystem stores said result packetin its buffer memory.

The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 265, 266,267, 268, 269).

FIG. 22 provides a sequence diagram showing an interrupt outputtransfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (260) within the Host generates anotification of output data followed by output data, addressed to aparticular USB function. Said notification and output data aretransmitted to the LEX subsystem as an OUT packet and a DATAX packet(OUT/DATAX packets). Said DATAX packet represents either a DATA0 packetor a DATA1 packet. On receipt of the OUT/DATAX packets, the controllogic (261) within the LEX subsystem generates a synthetic negativeacknowledgement packet and transmits the same to the Host as a NAKpacket. Said NAK packet warns the Host that it will not receive aresponse to its request and enables said Host to progress to the nexttransaction. The control logic (261) within the LEX subsystem forwardssaid OUT/DATAX packets to the REX-FPGA subsystem. The control logic(262) within the REX-FPGA subsystem forwards said OUT/DATAX packets tothe REX-Hub. The control logic (263) within the REX-Hub forwards saidOUT/DATAX packets to the Device. The information is received by thecontrol logic within the device.

On receipt of the OUT/DATAX packets, the control logic (264) within thedevice generates an acknowledgement and transmits the same as a Resultpacket to the REX-Hub. The control logic (263) within the REX-Hubforwards said Result packet to the REX-FPGA subsystem. The control logic(262) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem. The control logic (261) within the LEX subsystem storessaid Result packet in its buffer memory.

In Microframe Y₁, the control logic (265) within the Host recognizesthat it has not received an acknowledgement from the device. Saidcontrol logic generates a second notification of output data and outputdata, addressed to the same USB function. Said notification and outputdata are transmitted to the LEX subsystem as OUT/DATAX packets. Onreceipt of said OUT/DATAX packets, the control logic (266) within theLEX subsystem recognizes that it has a Result packet stored in memoryfrom the same function identified by the further OUT/DATAX packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same to the Host. Said further OUT/DATAX packets aretransmitted to the device in the same manner as the previous OUT/DATAXpackets. The information is then received by the control logic (269)within the device.

On receipt of the OUT/DATAX packets, the control logic (269) within thedevice generates an acknowledgement and transmits the same as a Resultpacket to the REX-Hub. Said Result packet is then transmitted to andstored in the LEX subsystem in the same manner as the previous Resultpacket.

The above-described process is repeated for subsequent notifications ofoutput data and output data from the Host by the distributed controllogic (e.g. 265, 266, 267, 268, 269).

FIG. 23 provides a sequence diagram showing a high bandwidth interruptinput transfer, between a high-speed host and a high-speed device,according to the invention. In Microframe Y₀, the control logic (280)within the Host generates a request for input data, addressed to aparticular USB function. Said request is transmitted to the LEXsubsystem as an IN packet. On receipt of said IN packet, the controllogic (281) within the LEX subsystem recognizes the lack of data thatcorresponds to the input request in its buffer memory. Said controllogic (281) then generates a synthetic data packet and transmits thesame as a NULL packet to the Host. Said synthetic data packet is a datapacket containing a zero length data payload and is used to satisfy thetiming requirements of the USB protocol while causing no disturbance tothe actual information being carried by the protocol. The control logic(281) within the LEX subsystem forwards the IN packet to the REX-FPGAsubsystem. The control logic (282) within the REX-FPGA subsystemforwards said IN packet to the REX-Hub. The control logic (283) withinthe REX-Hub forwards said request for input data as an IN packet to theDevice. The control logic (284) within the device assembles therequested interrupt data and transmits the same as a Result packet tothe REX-Hub. The control logic (283) within the REX-Hub forwards theResult packet to the REX-FPGA subsystem. On receipt of said Resultpacket, the control logic (282) within the REX-FPGA subsystem generatesa synthetic acknowledgement packet that is transmitted as an ACK packetto the REX-Hub. The control logic (283) within the REX-Hub forwards saidACK packet to the Device. The control logic (282) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (281) within the LEX subsystem stores said result packetin its buffer memory.

In the same microframe, Microframe Y₀, the control logic (280) withinthe Host generates a second request for input data, addressed to thesame USB function. Said request is transmitted to the LEX subsystem asan IN packet. On receipt of said IN packet, the control logic (281)within the LEX subsystem recognizes the lack of data that corresponds tothe input request in its buffer memory. Said control logic (281) thengenerates a synthetic data packet and transmits the same as a NULLpacket to the Host. The second IN packet is then transmitted to theDevice in the same manner as the previous IN packet.

On receipt of the second request for input data, the control logic (284)within the device assembles the requested interrupt data and transmitsthe same as a second Result packet to the REX-Hub. The control logic(283) within the REX-Hub forwards said Result packet to the REX-FPGAsubsystem. On receipt of said Result packet, the control logic (282)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the REX-Hub. The controllogic (283) within the REX-Hub forwards said ACK packet to the device.The control logic (282) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem and the control logic (281) withinthe LEX subsystem stores said result packet in its buffer memory.

In the same microframe, Microframe Y₀, the control logic (280) withinthe Host generates a third request for input data, addressed to the sameUSB function. Said request is transmitted to the LEX subsystem as an INpacket. On receipt of said IN packet, the control logic (281) within theLEX subsystem recognizes the lack of data that corresponds to the inputrequest in its buffer memory. Said control logic (281) then generates asynthetic negative acknowledgement packet and transmits the same as aNAK packet to the Host. Said NAK packet warns the Host that it will notreceive a response to its request and enables said Host to progress tothe next transaction. The third IN packet is then transmitted to theDevice in the same manner as the first and second IN packets.

On receipt of the third request for input data, the control logic (284)within the device assembles the requested interrupt data and transmitsthe same as a third Result packet to the REX-Hub. The control logic(283) within the REX-Hub forwards said Result packet to the REX-FPGAsubsystem. On receipt of said Result packet, the control logic (282)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the REX-Hub. The controllogic (283) within the REX-Hub forwards said ACK packet to the device.The control logic (282) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem and the control logic (281) withinthe LEX subsystem stores said Result packet in its buffer memory.

In the next microframe, Microframe Y₁, the control logic (285) withinthe Host recognizes that it has not received the requested data andautomatically retries the transaction by generating a further requestaddressed to the same USB function as in Microframe Y₀. Said furtherrequest is transmitted to the LEX subsystem as an IN packet. On receiptof said IN packet, the control logic (286) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further IN packet Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the Host. When the control logic (285) of the Host receivesthe requested Result packet from the LEX, said control logic generatesan ACK packet to acknowledge a successful transmission. Upon receipt ofthe ACK packet from the host, the control logic (286) within the LEXsubsystem absorbs said packet Said control logic (286) forwards thefurther IN packet to the REX-FPGA subsystem. The control logic (287)within the REX-FPGA forwards said IN packet to the REX-Hub. The controllogic (288) within the REX-Hub forwards said request for input data asan IN packet to the Device.

On receipt of the request for input data, the control logic (289) withinthe device assembles the requested interrupt data and transmits the sameas a Result packet to the REX-Hub. The control logic (288) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Onreceipt of said Result packet, the control logic (287) within theREX-FPGA subsystem generates a synthetic acknowledgement packet that istransmitted as an ACK packet to the REX-Hub. The control logic (288)within the REX-Hub forwards said ACK packet to the device. The controllogic (287) within the REX-FPGA subsystem forwards said Result packet tothe LEX subsystem and the control logic (286) within the LEX subsystemstores said Result packet in its buffer memory.

Within the same microframe, Microframe Y₁, the control logic (285)within the Host generates a second request for input data. Said requestis transmitted to the LEX subsystem as an IN packet. The control logic(286) within the LEX subsystem retrieves the second stored Result packetfrom the previous microframe and transmits the same packet to the Host.When the control logic (285) of the Host receives the requested Resultpacket from the LEX, said control logic generates an ACK packet toacknowledge a successful transmission. Upon receipt of the ACK packetfrom the host, the control logic (286) within the LEX subsystem absorbssaid packet. Said second IN packet is forwarded to the device in thesame manner as previous IN packets.

On receipt of the second request for input data, the control logic (289)within the device assembles the requested interrupt data and transmitsthe same as a Result packet. Said Result packet is transmitted to andstored in the LEX subsystem in the same manner as previous Resultpackets. On receipt of said result packet, the control logic (287)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the device in the samemanner as previous synthetic ACK packets.

Within the same microframe, Microframe Y₁, the control logic (285)within the host generates a third request for input data. Said requestis transmitted to the LEX subsystem as an IN packet. The control logic(286) within the LEX subsystem retrieves the third stored Result packetfrom the previous microframe and transmits the same packet to the Host.When the control logic (285) of the Host receives the requested Resultpacket from the LEX, said control logic generates an ACK packet toacknowledge a successful transmission. Upon receipt of the ACK packetfrom the host, the control logic (286) within the LEX subsystem absorbssaid packet. Said third IN packet is forwarded to the device in the samemanner as previous IN packets.

On receipt of the third request for input data, the control logic (289)within the device assembles the requested interrupt data and transmitsthe same a Result packet. Said Result packet is transmitted to andstored in the LEX subsystem in the same manner as previous Resultpackets. On receipt of said result packet, the control logic (287)within the REX-FPGA subsystem generates a synthetic acknowledgementpacket that is transmitted as an ACK packet to the device in the samemanner as previous synthetic ACK packets.

The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 285, 286,287, 288 & 289).

FIG. 24 provides a sequence diagram showing a high bandwidth interruptoutput transfer, between a high-speed host and a high-speed device. InMicroframe Y₀, the control logic (280) within the Host generates anotification of output data followed by output data, addressed to aparticular USB function. Said notification of output data and outputdata are transmitted to the LEX subsystem as an OUT packet and a DATAXpacket (OUT/DATAX packets). Said DATAX packet represents either a DATA0packet or DATA1 packet. On receipt of said OUT/DATAX packets, thecontrol logic (281) within the LEX subsystem generates a syntheticacknowledgement packet and transmits the same as an ACK packet to theHost. Said synthetic acknowledgement packet tells the host that the datatransmission is successful and enables said host to progress to the nexttransaction. The control logic (281) within the LEX subsystem forwardsthe OUT/DATAX packets to the REX-FPGA subsystem. The control logic (282)within the REX-FPGA subsystem forwards said OUT/DATAX packets to theREX-Hub. The control logic (283) within the REX-Hub forwards saidOUT/DATAX packets to the Device.

The control logic (284) within the device generates a Result packetcorresponding to the OUT/DATAX packets and transmits the same to theREX-Hub. The control logic (283) within the REX-Hub forwards said Resultpacket to the REX-FPGA subsystem. The control logic (282) within theREX-FPGA subsystem forwards said Result packet to the LEX subsystem andthe control logic (281) within the LEX subsystem stores said Resultpacket in its buffer memory.

In the same microframe, Microframe Y₀, the control logic (280) withinthe Host generates a second notification of output data and output data,addressed to the same USB function. Said notification and output dataare transmitted to the LEX subsystem as OUT/DATAX packets. On receipt ofsaid OUT/DATAX packets, the control logic (281) within the LEX subsystemgenerates a synthetic acknowledgement packet and transmits the same asan ACK packet to the Host. The second OUT/DATAX packets are thentransmitted to the Device in the same manner as the previous OUT/DATAXpackets. On receipt of the second notification of output data and outputdata, the control logic (284) within the device generates a secondResult packet and transmits the same to the REX-Hub. The control logic(283) within the REX-Hub forwards said Result packet to the REX-FPGAsubsystem. The control logic (282) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem and the control logic(281) within the LEX subsystem stores said result packet in its buffermemory.

In the same microframe, Microframe Y₀, the control logic (280) withinthe Host generates a third notification of output data and output data,addressed to the same USB function. Said notification and output dataare transmitted to the LEX subsystem as OUT/DATAX packets. On receipt ofsaid OUT/DATAX packets, the control logic (281) within the LEX subsystemgenerates a synthetic negative acknowledgement packet and transmits thesame as an NAK packet to the Host. Said NAK packet warns the Host thatit will not receive a data transmission status to the notification ofoutput data and enables said Host to progress to the next transaction.The third OUT/DATAX packets are then transmitted to the Device in thesame manner as the first two OUT/DATAX packets.

On receipt of the third notification of output data and output data, thecontrol logic (284) within the device generates a third Result packetand transmits the same to the REX-Hub. The control logic (283) withinthe REX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (282) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (281) within the LEXsubsystem stores said result packet in its buffer memory.

In Microframe Y₁, the control logic (285) within the Host generates anotification of output data followed by output data, addressed to thesame USB function. Said notification and output data are transmitted tothe LEX subsystem as OUT/DATAX packets. On receipt of said OUT/DATAXpackets, the control logic (286) within the LEX subsystem recognizesthat it has a Result packet stored in memory from the same functionidentified by the further OUT/DATAX packets. Said control logicretrieves said stored Result packet from memory and transmits the sameto the Host. Said further OUT/DATAX packets are transmitted to thedevice in the same manner as the previous OUT/DATAX packets. Theinformation is received by the control logic (289) within the device.

On receipt of the OUT/DATAX packets, the control logic (289) within thedevice generates a Result packet and transmits the same to the REX-Hub.Said Result packet is then transmitted to and stored in the LEXsubsystem in the same manner as the previous Result packets.

In the same microframe, Microframe Y₁, the control logic (285) withinthe Host generates a second notification of output data and output data,addressed to the same USB function. Said notification and output dataare transmitted to the LEX subsystem as OUT/DATAX packets. On receipt ofsaid OUT/DATAX packets, the control logic (286) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further OUT/DATAX packets. Said control logicretrieves said stored Result packet from memory and transmits the sameas a Result packet to the Host. Said further OUT/DATAX packets aretransmitted to the device in the same manner as the previous OUT/DATAXpackets. The information is received by the control logic (289) withinthe device.

On receipt of the OUT/DATAX packets, the control logic (289) within thedevice generates a Result packet and transmits the same to the REX-Hub.Said Result packet is then transmitted to and stored in the LEXsubsystem in the same manner as the previous Result packets.

In the same microframe, Microframe Y₁, the control logic (285) withinthe Host generates a third notification of output data and output data,addressed to the same USB function. Said notification and output dataare transmitted to the LEX subsystem as OUT/DATAX packets. On receipt ofsaid OUT/DATAX packets, the control logic (286) within the LEX subsystemrecognizes that it has a Result packet stored in memory from the samefunction identified by the further OUT/DATAX packets. Said control logicretrieves said stored Result packet from memory and transmits the sameas a Result packet to the Host. Said further OUT/DATAX packets aretransmitted to the device in the same manner as the previous OUT/DATAXpackets. The information is received by the control logic (289) withinthe device.

On receipt of the OUT/DATAX packets, the control logic (289) within thedevice generates a Result packet and transmits the same to the REX-Hub.Said Result packet is then transmitted to and stored in the LEXsubsystem in the same manner as the previous Result packets.

The above-described process is repeated for subsequent notifications ofoutput data and output data from the Host by the distributed controllogic (e.g. 285, 286, 287, 288, & 289).

FIG. 25 provides a simplified timing diagram showing control and bulkdata transfers, which are two special cases of asynchronous transfers,according to the USB protocol. The diagram is constructed from the pointof view of a USB Host Controller, normally included on a PC motherboard(Host PC). For a full-speed host, the USB protocol divides timeallocation on the shared bus into regular Frames, each of 1 ms induration. For a high-speed host, time allocation on the shared bus isdivided into regular Microframes, each of 125 _(μ)s in duration. Thestart of each microframe is identified in the diagram as I1, I2, . . . ,I_(n), . . . , I_(n+k), etc., where n and k are positive integers.

When a Host Controller is engaged upon a control or bulk data transferwith a device, the Host Controller issues requests for data transfer tosaid device on an as needed basis. These requests are identified in FIG.25 as packets, R1 & R2 (10 & 13). Under the USB protocol, a USB devicemust respond to the request from a full speed host within 16 full-speedbit-times. In response to requests from a high-speed host, a USB devicemust respond within 736 high-speed bit-times. Control and bulk devicesare not required to respond to a request within the same microframewhere said request is generated. However, control and bulk devices mustrespond within the same frame where a request is generated becausecontrol and bulk transactions are not allowed to span a frame boundary.The responses generated by the device are shown in the diagram aspackets A1 & A2 (11 & 14). On receipt of a response packet, the HostController also emits an acknowledgement and these acknowledgements areidentified as packets K1 & K2 (12 & 15). It is commonly expected thattransfer A1 (11) will be delivered in response to request R1 (10) andacknowledgement K1 (12) will be emitted on receipt of R1 (10) within thesame frame, transfer A2 (14) will be delivered in response to request R2(13) and acknowledgement K2 (15) will be emitted on receipt of R2 (13)within the same frame, and so on until the requests are terminated. Forcontrol and bulk transfers, data requests are not generated periodicallyand transfers can take place anytime when the shared bus has unoccupiedbandwidth. Request R2 (13) may be generated immediately afteracknowledgement K1 (12) is received or said request may be generatedseveral microframes after K1 (12) is received. The time elapsed betweenK1 (12) and R2 (13) depends on the bandwidth availability on the sharedbus at that particular time and the same is true for subsequentrequests. The time span within which a transaction takes place is notfixed and is identified by “Time” in FIG. 25.

FIG. 26 provides a simplified timing diagram showing control and bulkdata transfers, two special cases of asynchronous transfers, accordingto the present invention. The diagram shows the progression of packetsthrough the various subsystems comprising the invention. Timelines arepresented for the Host PC (1), Local Expander (4) and Remote ExpanderFPGA (8) subsystems. Each transaction may take place in the span of oneor more microframes but must be completed before the arrival of thesubsequent frame boundary. The elapsed time between consecutive requestsis not fixed and may be less than one microframe, one microframe, ormore than one microframe. The time span within which each transactiontakes place is identified by “Time” in FIG. 26.

An asynchronous transfer is initiated from a Host PC by emitting arequest for input data R1 (20) to a particular USB address andend-point. Said request R1 (20) is received by the LEX and retransmittedas R1 (25) over the external cabling to the REX-FPGA. Said retransmittedpacket R1 (25) is received by the REX-FGPA and forwarded as R1 (31) tothe REX-Hub. A synthetic negative acknowledgement packet is generated bythe LEX and transmitted as N1 (26) to the host.

The target device generates an input data packet A1 (32). According tothe USB protocol for low-speed and full-speed isochronous transfers, adevice with a detachable cable must generate a response within 6.5full-speed bit-times of the end of the corresponding request. Forhigh-speed isochronous transfers, a device must generate a responsewithin 192 high-speed bit times. Said input data packet A1 (32) isreceived by the REX-Hub and the REX-FPGA subsystem and retransmitted asA1 (27) over the external wiring to the LEX. Said retransmitted responseA1 (27) is not immediately forwarded to the Host PC, but is storedwithin the memory of the LEX subsystem. A synthetic acknowledgementpacket K1 (33) is generated by the REX-FGPA subsystem and transmitted asK1 (33) to the REX-Hub.

The Host PC (1) notices that it did not receive data in response to itsrequest R1 (20), and retries the transaction by generating a furtherrequest R2 (22) to the same USB address and end-point. Upon receivingrequest R2 (28), the LEX subsystem retrieves response A1 (27) from itsmemory buffers and forwards it to the Host PC as response A1 (29). Saidresponse is received by the Host as response A1 (23) and said request R2(28) is absorbed by the LEX subsystem. Upon receiving said response A1(23), the Host generates an acknowledgement packet and transmits thepacket as packet K1 (24) to the LEX subsystem. Said acknowledgementpacket K1 (30) is received and absorbed by LEX.

The above-described protocol sequence is repeated for each initial inputdata request generated by the Host Controller.

FIG. 27 is a sequence diagram showing a control input transfer, betweena high-speed host and a low-speed device. In the Set-up Phase, thecontrol logic (340) within the Host generates a start split-transaction,a notification of device set-up, and a data packet addressed to aparticular USB function. Said split-transaction, notification, and dataare transmitted to the LEX subsystem as a SSPLIT packet, a SETUP packet,and a DATA0 packet, respectively. On receipt of said SSPLIT/SETUP/DATA0packets, the control logic (341) within the LEX subsystem recognizes ithas not yet received an acknowledgement from the device so said controllogic generates a synthetic negative acknowledgement and transmits thesame to the host as a NAK packet. The control logic (341) within the LEXsubsystem forwards said SSPLIT/SETUP/DATA0 packets to the REX-FPGAsubsystem. The control logic (342) within the REX-FPGA subsystemforwards said SSPLIT/SETUP/DATA0 packets to the REX-Hub. On receipt ofsaid SSPLIT/SETUP/DATA0 packets, the control logic (343) within theREX-Hub generates an acknowledgement and transmits the same as an ACKpacket to the REX-FPGA subsystem. The control logic (342) within theREX-FPGA subsystem forwards said ACK packet to the LEX subsystem and thecontrol logic (341) within the LEX subsystem stores said ACK packet inits buffer memory. The control logic (343) within the REX-Hub absorbssaid SSPLIT packet and forwards said SETUP/DATA0 packets to the Device.

Upon successful receipt of the SETUP/DATA0 packets, the control logic(344) within the device generates an acknowledgement and transmits thesame as a Result packet to the REX-Hub. The control logic (343) withinthe REX-Hub stores said Result packet in its buffer memory.

At a later time, the control logic (340) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing further SSPLIT/SETUP/DATA0 packetsaddressed to the same USB function. On receipt of saidSSPLIT/SETUP/DATA0 packets, the control logic (341) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further SSPLIT/SETUP/DATA0 packets.Said control logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (341) alsorecognizes that said SSPLIT/SETUP/DATA0 packets are merely a repetitionof the previous SSPLIT/SETUP/DATA0 packets and absorbs said packets.

At a later time, the control logic (340) within the host generates acomplete split-transaction and a notification of device set-up. Saidcomplete split-transaction and notification of device set-up aretransmitted to the LEX subsystem as a CSPLIT packet and a SETUP packet(CSPLIT/SETUP packets). On receipt of the CSPLIT/SETUP packets, thecontrol logic (341) within the LEX subsystem recognizes that it has notreceived an acknowledgement from the device so said control logic (341)generates a NYET packet and transmits the same to the host. Said NYETpacket warns the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. Said control logic (341) forwards said CSPLIT/SETUP packetsto the REX-FPGA subsystem. The control logic (342) within the REX-FPGAsubsystem forwards said CSPLIT/SETUP packets to the REX-Hub.

On receipt of the CSPLIT/SETUP packets, the control logic (343) withinthe REX-Hub recognizes that it has an acknowledgement packet stored inmemory. Said control logic retrieves said stored acknowledgement packetfrom memory and transmits the same packet as a Result packet to theREX-FPGA subsystem. The control logic (342) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (341) within the LEX subsystem stores said Result packet in Itsbuffer memory.

At a later time, the control logic (340) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing a further complete split-transactionand a notification of device set-up, addressed to the same USB function.Said complete split-transaction and notification of device set-up aretransmitted to the LEX subsystem as further CSPLIT/SETUP packets. Onreceipt of said further CSPLIT/SETUP packets, the control logic (341)within the LEX subsystem recognizes that it has an acknowledgementpacket stored in memory from the same function identified by the furtherCSPLIT/SETUP packets. Said control logic retrieves said storedacknowledgement packet from memory and transmits the same as a Resultpacket to the Host Said control logic (341) also recognizes that saidCSPLIT/SETUP packets are merely a repetition of the previousCSPLIT/SETUP packets and absorbs said packets.

In the Data Phase, the control logic (345) within the host generates astart split-transaction and a request for input data addressed to thesame USB function as the Set-up Phase. Said start split-transaction andrequest for input data are transmitted to the LEX subsystem as a SSPLITpacket and an IN packet (SSPLIT/IN packets). On receipt of the SSPLIT/INpackets, the control logic (346) within the LEX subsystem recognizesthat it has not received an acknowledgement from the device so saidcontrol logic generates a synthetic negative acknowledgement andtransmits the same to the host as a NAK packet. Said control logic (346)forwards said SSPLIT/IN packets to the REX-FPGA subsystem. The controllogic (347) within the REX-FPGA subsystem forwards said SSPLIT/INpackets to the REX-Hub.

On receipt of the SSPLIT/IN packets, the control logic (348) within theREX-Hub generates an acknowledgement packet and transmits the same tothe REX-FPGA subsystem as a Result packet. The control logic (347)within the REX-FPGA subsystem forwards said Result packet to the LEXsubsystem and the control logic (346) within the LEX subsystem storessaid Result packet in its buffer memory. The control logic (348) withinthe REX-Hub forwards the request for input data as an IN packet to thedevice. On receipt of said IN packet, the control logic (349) within thedevice assembles the requested data and transmits the same as a Resultpacket to the REX-Hub. The control logic (348) within the REX-Hub storessaid Result packet in its buffer memory. On receipt of the Resultpacket, said control logic (348) generates an ACK packet to acknowledgea successful transmission.

At a later time, the control logic (345) within the host recognizes thatit has not received the requested data from the device and automaticallyretries the transaction by issuing a further start split-transaction anda request for input data addressed to the same USB function. Said startsplit-transaction and request for input data are transmitted as aSSPLIT/IN packets to the LEX subsystem. On receipt of the SSPLIT/INpackets, the control logic (346) within the LEX subsystem recognizesthat it has an acknowledgement packet stored in memory from the samefunction identified by the further SSPLIT/IN packets. Said control logicretrieves the stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host. Said control logic (346) alsorecognizes that said SSPLIT/IN packets are merely a repetition of theprevious SSPLIT/IN packets and absorbs said packets.

At a yet later time, the control logic (345) within the host generates acomplete split-transaction and a request for input data, addressed tothe same USB function. Said complete split-transaction and request forinput data are transmitted to the LEX subsystem as a CSPLIT packet andan IN packet (CSPLIT/IN PACKETS). On receipt of the CSPLIT/IN packets,the control logic (346) within the LEX subsystem recognizes that it hasnot received an acknowledgement packet from the device so said controllogic generates a synthetic NYET packet and transmits the same to thehost. Said NYET packet informs the host that the LEX subsystem has notyet received a response from the device and enables said host toprogress to the next transaction. The control logic (346) within the LEXsubsystem forwards said CSPLIT/IN packets to the REX-FPGA subsystem. Thecontrol logic (436) within the REX-FPGA subsystem forwards saidCSPLIT/IN packets to the REX-Hub.

On receipt of the CSPLIT/IN packets, the control logic (348) within theREX-Hub recognizes that it has in its buffer memory a Result packet thatcorresponds to the input data request. Said control logic (348)retrieves said stored Result packet and transmits the same to theREX-FPGA subsystem. The control logic (347) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (346) within the LEX subsystem stores said Result packetin its buffer memory.

At a later time, the control logic (345) within the host recognizes thatit has not received the requested data from the device and automaticallyretries the transaction by issuing a further complete split-transactionand a request for input data, addressed to the same USB function. Saidcomplete split-transaction and request for input data are transmitted tothe LEX subsystem as further CSPLIT/IN packets. On receipt of thefurther CSPLIT/IN packets, the control logic (346) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further CSPLIT/IN packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (346) alsorecognizes that said CSPLIT/IN packets are merely a repetition of theprevious CSPLIT/IN packets and absorbs said packets.

In the Status Phase, the control logic (350) within the host generates astart split-transaction, a notification of output data, and a datapacket addressed to the same USB function as the Data Phase. Said startsplit-transaction, notification of output data, and data packet aretransmitted as SSPLIT/OUT/DATA1 packets to the LEX subsystem. On receiptof the SSPLIT/OUT/DATA1 packets, the control logic (351) within the LEXsubsystem recognizes that it has not received an acknowledgement fromthe device so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet. Saidcontrol logic (351) forwards said SSPLIT/OUT/DATA1 packets to theREX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said SSPLIT/OUT/DATA1 packets to the REX-Hub.

Upon successful receipt of the SSPLIT/OUT/DATA1 packets, the controllogic (353) within the REX-Hub generates an acknowledgement packet andtransmits the same to the REX-FPGA subsystem as a Result packet. Thecontrol logic (352) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (351) within the LEXsubsystem stores said Result packet in its buffer memory. The controllogic (353) within the REX-Hub absorbs said SSPLIT packet and forwardssaid OUT/DATA1 packets to the device. On receipt of said OUT/DATA1packets, the control logic (354) within the device generates anacknowledgement and transmits the same as a Result packet to theREX-Hub. The control logic (353) within the REX-Hub stores said Resultpacket in its buffer memory.

At a later time, the control logic (350) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing further SSPLIT/OUT/DATA1 packets tothe LEX subsystem. On receipt of the SSPLIT/OUT/DATA1 packets, thecontrol logic (351) within the LEX subsystem recognizes that it has anacknowledgement packet stored in memory from the same functionidentified by the further SSPLIT/OUT/DATA1 packets. Said control logicretrieves the stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host. Said control logic (351) alsorecognizes that said SSPLIT/OUT/DATA1 packets are merely a repetition ofthe previous SSPLIT/OUT/DATA1 packets and absorbs said packets.

At a yet later time, the control logic (350) within the host generates acomplete split-transaction and a notification of output data, addressedto the same USB function. Said complete split-transaction andnotification of output data are transmitted as CSPLIT/OUT packets to theLEX subsystem. On receipt of the CSPLIT/OUT packets, the control logic(351) within the LEX subsystem recognizes that it has not received anacknowledgement packet from the device so said control logic generates asynthetic NYET packet and transmits the same to the host. Said NYETpacket informs the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. The control logic (351) within the LEX subsystem forwardssaid CSPLIT/OUT packets to the REX-FPGA subsystem. The control logic(352) within the REX-FPGA subsystem forwards said CSPLIT/OUT packets tothe REX-Hub.

On receipt of the CSPLIT/OUT packets, the control logic (353) within theREX-Hub recognizes that it has in its buffer memory a Result packet thatcorresponds to the further CSPLIT/OUT packets. Said control logic (353)retrieves said stored Result packet and transmits the same to theREX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (351) within the LEX subsystem stores said Result packetin its buffer memory.

At a later time, the control logic (350) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing further CSPLIT/OUT packets to the LEXsubsystem. On receipt of the CSPLIT/OUT packets, the control logic (351)within the LEX subsystem recognizes that it has an acknowledgementpacket stored in memory from the same function Identified by the furtherCSPLIT/OUT packets. Said control logic retrieves said stored packet frommemory and transmits the same as a Result packet to the Host. Saidcontrol logic (351) also recognizes that said CSPLIT/OUT packets aremerely a repetition of the previous CSPLIT/OUT packets and absorbs saidpackets.

According to the invention, the protocol handling for control INtransfers between a high-speed host and a full-speed device is the sameas the protocol handling for control IN transfers between a high-speedhost and a low-speed device, as described in FIG. 27 by control logics(340) to (354).

FIG. 28 is a sequence diagram showing a control output transfer, betweena high-speed host and a low-speed device. In the Set-up Phase, thecontrol logic (340) within the Host generates start split-transaction, anotification of device set-up, and a data packet addressed to aparticular USB function. Said split-transaction, notification, and dataare transmitted to the LEX subsystem as SSPLIT/SETUP/DATA0 packets. Onreceipt of the SSPLIT/SETUP/DATA0 packets, the control logic (341)within the LEX subsystem recognizes the lack of Result that correspondsto the notification of device set-up in its memory so said control logicgenerates a synthetic negative acknowledgement and transmits the same tothe host as a NAK packet. The control logic (341) within the LEXsubsystem forwards said SSPLIT/SETUP/DATA0 packets to the REX-FPGAsubsystem. The control logic (342) within the REX-FPGA subsystemforwards said SSPLIT/SETUP/DATA0 packets to the REX-Hub. On receipt ofsaid SSPLIT/SETUP/DATA0 packets, the control logic (343) within theREX-Hub generates an acknowledgement and transmits the same as an ACKpacket to the REX-FPGA subsystem. The control logic (342) within theREX-FPGA subsystem forwards said ACK packet to the LEX subsystem and thecontrol logic (341) within the LEX subsystem stores said ACK packet inits buffer memory. The control logic (343) within the REX-Hub forwardssaid SETUP/DATA0 packets to the Device.

On receipt of the SETUP/DATA0 packets, the control logic (344) withinthe device assembles the requested Result and transmits the same as aResult packet to the REX-Hub. The control logic (343) within the REX-Hubstores said Result packet in its buffer memory.

At a later time, the control logic (340) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing further SSPLIT/SETUP/DATA0 packets tothe LEX subsystem. On receipt of the SSPLIT/SETUP/DATA0 packets, thecontrol logic (341) within the LEX subsystem recognizes that it has anacknowledgement packet stored in memory from the same functionidentified by the further SSPLIT/SETUP/DATA0 packets. Said control logicretrieves said stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host. Said control logic (341) alsorecognizes that said SSPLIT/SETUP/DATA0 packets are a repetition of theprevious SSPLIT/SETUP/DATA0 packets and absorbs said packets.

At a later time, the control logic (340) within the host generates acomplete split-transaction and a notification of device set-up. Saidcomplete split-transaction and notification of device set-up aretransmitted to the LEX subsystem as a CSPLIT packet and a SETUP packet(CSPLIT/SETUP packets). On receipt of the CSPLIT/SETUP packets, thecontrol logic (341) within the LEX subsystem recognizes the lack ofResult that corresponds to the notification of data set-up in its memoryso said control logic (341) generates a NYET packet and transmits thesame to the host. Said NYET packet warns the host that the LEX subsystemhas not yet received a response from the device and enables said host toprogress to the next transaction. Said control logic (341) forwards saidCSPLIT/SETUP packets to the REX-FPGA subsystem. The control logic (342)within the REX-FPGA subsystem forwards said CSPLIT/SETUP packets to theREX-Hub.

On receipt of the CSPLIT/SETUP packets, the control logic (343) withinthe REX-Hub recognizes that it has a Result packet stored in memory.Said control logic retrieves said stored Result packet from memory andtransmits the same packet as a Result packet to the REX-FPGA subsystem.The control logic (342) within the REX-FPGA subsystem forwards saidResult packet to the LEX subsystem. The control logic (341) within theLEX subsystem stores said Result packet in its buffer memory.

At a later time, the control logic (340) within the host recognizes thatit has not received a Result from the device and automatically retriesthe transaction by Issuing further CSPLIT/SETUP packets to the LEXsubsystem. On receipt of the further CSPLIT/SETUP packets, the controllogic (341) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherCSPLIT/SETUP packet. Said control logic (341) retrieves said storedResult packet from memory and transmits the same packet to the Host.

In the Data Phase, the control logic (345) within the host generates astart split-transaction, a notification of output data, and a datapacket, addressed to the same USB function as the Set-up Phase. Saidstart split-transaction, notification of output data, and data packetare transmitted to the LEX subsystem as a SSPLIT packet, an OUT packet,and a DATA1 packet, respectively (SSPLIT/OUT/DATA1 packets). On receiptof the SSPLIT/OUT/DATA1 packets, the control logic (346) within the LEXsubsystem recognizes the lack of Result that corresponds to the inputrequest in its buffer memory so said control logic generates a syntheticnegative acknowledgement and transmits the same to the host as a NAKpacket. Said control logic (346) forwards said SSPLIT/OUT/DATA1 packetsto the REX-FPGA subsystem. The control logic (347) within the REX-FPGAsubsystem forwards said SSPLIT/OUT/DATA1 packets to the REX-Hub.

On receipt of the SSPLIT/OUT/DATA1 packets, the control logic (348)within the REX-Hub generates an acknowledgement packet and transmits thesame to the REX-FPGA subsystem as a Result packet. The control logic(347) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (346) within the LEX subsystemstores said Result packet in its buffer memory. The control logic (348)within the REX-Hub absorbs said SSPLIT packet and forwards saidOUT/DATA1 packets to the device. On receipt of said OUT/DATA1 packets,the control logic (349) within the device assembles the requested Resultand transmits the same as a Result packet to the REX-Hub. The controllogic (348) within the REX-Hub stores said Result packet in its buffermemory.

At a later time, the control logic (345) within the host recognizes thatit has not received the requested Result and automatically retries thetransaction by issuing further SSPLIT/OUT/DATA1 packets to the LEXsubsystem. On receipt of the SSPLIT/OUT/DATA1 packets, the control logic(346) within the LEX subsystem recognizes that it has a Result packetstored in memory from the same function identified by the furtherSSPLIT/OUT/DATA1 packets. Said control logic retrieves said storedResult packet from memory and transmits the same packet to the Host Saidcontrol logic (346) also recognizes that said SSPLIT/OUT/DATA1 packetsare a repetition of the previous SSPLIT/OUT/DATA1 packets and absorbssaid packets.

At a yet later time, the control logic (345) within the host generates acomplete split-transaction and a notification of output data. Saidcomplete split-transaction and notification of output data aretransmitted to the LEX subsystem as a CSPLIT packet and an OUT packet(CSPLIT/OUT packets). On receipt of the CSPLIT/OUT packets, the controllogic (346) within the LEX subsystem recognizes the lack of Result thatcorresponds to the notification of output data in its memory so saidcontrol logic (346) generates a NYET packet and transmits the same tothe host. Said NYET packet warns the host that the LEX subsystem has notyet received a response from the device and enables said host toprogress to the next transaction. Said control logic (346) forwards saidCSPLIT/SETUP packets to the REX-FPGA subsystem. The control logic (347)within the REX-FPGA subsystem forwards said CSPLIT/OUT packets to theREX-Hub.

On receipt of the CSPLIT/OUT packets, the control logic (348) within theREX-Hub recognizes that it has a Result packet stored in memory from thesame function identified by the CSPLIT/OUT packets. Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the REX-FPGA subsystem. The control logic (347) within theREX-FPGA subsystem forwards said Result packet to the LEX subsystem andthe control logic (346) within the LEX subsystem stores said Resultpacket in its buffer memory.

At a later time, the control logic (345) within the host recognizes thatit has not received the requested Result and automatically retries thetransaction by issuing a further CSPLIT packet and a further OUT packetto the LEX subsystem. On receipt of the CSPLIT/OUT packets, the controllogic (346) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherCSPLIT/OUT packets. Said control logic retrieves said stored Resultpacket from memory and transmits the same packet to the Host. Saidcontrol logic (346) also recognizes that said CSPLIT/OUT packets are arepetition of the previous CSPLIT/OUT packets and absorbs said packets.

In the Status Phase, the control logic (350) within the host generates astart split-transaction and a request for input data, addressed to thesame USB function as the Data Phase. Said start split-transaction andrequest for input data are transmitted to the LEX subsystem as a SSPLITpacket and an IN packet (SSPLIT/IN packets). On receipt of saidSSPLIT/IN packets, the control logic (351) within the LEX subsystemrecognizes that the lack of Result in its memory so it generates asynthetic negative acknowledgement and transmits the same as a NAKpacket to the host. Said control logic forwards the SSPLIT/IN packets tothe REX-FPGA subsystem. The control logic (352) within the REX-FPGAsubsystem forwards said SSPLIT/IN packets to the REX-Hub. On receipt ofthe SSPLIT/IN packets, the control logic (353) within the REX-Hubgenerates a Result and transmits the same as a Result packet to theREX-FPGA subsystem. The control logic (352) within the REX-FGPAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (351) within the LEX subsystem stores said Result packetin its buffer memory. The control logic (353) within the REX-Hub absorbssaid SSPLIT packet and forwards said IN packet to the device.

On receipt of the IN packet, the control logic (354) within the deviceassembles the requested data and transmits the same as a Result packetto the REX-Hub. Upon receipt of the Result packet, the control logic(353) within the REX-Hub generates an ACK packet to acknowledge asuccessful transmission and transmits the same to the device.

At a later time, the control logic (350) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing a further SSPLIT packet and a furtherIN packet to the LEX subsystem. On receipt of the further SSPLIT/INpackets, the control logic (351) within the LEX subsystem recognizesthat it has an acknowledgement packet stored in memory from the samefunction identified by the further SSPLIT/IN packets. Said control logicretrieves said stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host. Said control logic alsorecognizes that said SSPLIT/IN packets are a repetition of the previousSSPLIT/IN packets and absorbs said packets.

At a yet later time, the control logic (350) within the host generates acomplete split-transaction and a request for input data. Said completesplit-transaction and request for input data are transmitted to the LEXsubsystem as a CSPLIT packet and an IN packet (CSPLIT/IN packets). Onreceipt of the CSPLIT/IN packets, the control logic (351) within the LEXsubsystem recognizes the lack of data that corresponds to the request inits memory so said control logic (351) generates a NYET packet andtransmits the same to the host. Said NYET packet warns the host that theLEX subsystem has not yet received a response from the device andenables said host to progress to the next transaction. Said controllogic (351) forwards said CSPLIT/IN packets to the REX-FPGA subsystem.The control logic (352) within the REX-FPGA subsystem forwards saidCSPLIT/IN packets to the REX-Hub.

At a later time, the control logic (350) within the host recognizes thatit has not received a data packet from the device and automaticallyretries the transaction by issuing a further CSPLIT packet and a furtherIN packet to the LEX subsystem. On receipt of the further CSPLIT/INpackets, the control logic (351) within the LEX subsystem recognizesthat it has a data packet stored in memory from the same functionidentified by the further CSPLIT/IN packets. Said control logicretrieves said stored Result packet from memory and transmits the samepacket to the Host. Said control logic also recognizes that saidCSPLIT/IN packets are a repetition of the previous CSPLIT/IN packets andabsorbs said packets.

According to the invention, the protocol handling for control outputtransfers between a high-speed host and a full-speed device is the sameas the protocol handling for control output transfers between ahigh-speed host and a low-speed device, as described in FIG. 28 bycontrol logics (340) to (354).

FIG. 29 is a sequence diagram showing a control input transfer, betweena high-speed host and a high-speed device. In the Set-up Phase, thecontrol logic (360) within the Host generates a notification of deviceset-up and a data packet, addressed to a particular USB function. Saidnotification and data are transmitted to the LEX subsystem as a SETUPpacket and a DATA0 packet (SETUP/DATA0 packets). On receipt of saidpackets, the control logic (361) within the LEX subsystem recognizesthat it has not yet received an acknowledgment from the device so saidcontrol logic generates a synthetic acknowledgement packet and transmitsthe same as an ACK packet to the host Said control logic (361) forwardsthe SETUP/DATA0 packets to the REX-FPGA subsystem. The control logic(362) within the REX-FPGA subsystem forwards said SETUP/DATA0 packets tothe REX-Hub. The control logic (363) within the REX-Hub forwards saidSETUP/DATA0 packets to the Device.

On receipt of said SETUP/DATA0 packets, the control logic (364) withinthe device assembles the required acknowledgement packet and transmitsthe same as a Result packet to the Host The control logic (363) withinthe REX-Hub receives said Result packet and forwards the same packet tothe REX-FPGA subsystem. The control logic (362) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (361) within the LEX subsystem recognizes that it has already sentan acknowledgement to the host and absorbs said Result packet.

In the Data Phase, the control logic (365) within the host generates arequest for input data addressed to the same USB function, afterreceiving the first Result packet. Said request for input data aretransmitted to the LEX subsystem as an IN packet. On receipt of said INpacket, the control logic (366) within the LEX subsystem recognizes thelack of data that corresponds to the input request in its buffer memoryso said control logic generates a synthetic negative acknowledgementpacket and transmits the same as a NAK packet to the host. Said controllogic (366) forwards the IN packet to the REX-FPGA subsystem. Thecontrol logic (367) within the REX-FPGA subsystem forwards said INpacket to the REX-Hub. The control logic (368) within the REX-Hubforwards the request for input data to the Device as an IN packet.

On receipt of the IN packet, the control logic (369) within the deviceassembles the requested control data and transmits the same to theREX-Hub as a Result packet. The control logic (368) within the REX-Hubforwards said Result packet to the REX-FPGA subsystem. On receipt ofsaid Result packet, the control logic (367) within the REX-FPGAsubsystem generates a synthetic acknowledgement packet. Saidacknowledgement packet is transmitted to the REX-Hub as an ACK packet.The control logic (368) within the REX-Hub forwards said ACK packet tothe device. The control logic (367) within the REX-FPGA subsystemforwards said Result packet to the LEX subsystem and the control logic(366) within the LEX subsystem stores said Result packet in its buffermemory.

At a later time, the control logic (365) within the host recognizes thatit has not received the requested input data and automatically retriesthe transaction by issuing a further request addressed to the same USBfunction. Said request is transmitted to the LEX subsystem as an INpacket On receipt of the IN packet, the control logic (366) within theLEX subsystem recognizes that it has a Result packet stored in memoryfrom the same function identified by the further IN packet. Said controllogic retrieves said stored Result packet from memory and transmits thesame packet to the Host Said control logic (366) also recognizes thatsaid IN packet is a repetition of the previous IN packet and absorbssaid packet Upon successful receipt of the Result packet, the controllogic (365) within the host generates an ACK packet to acknowledge asuccessful transmission. When the control logic (366) within the LEXsubsystem receives the ACK packet from the host, said control logicabsorbs said packet.

The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 365, 366,367, 368, 369). The control logic within the host will continue togenerate requests for input data until the last data packet is received.

In the Status Phase, the control logic (370) within the host generates anotification of output data and a data packet, addressed to the same USBfunction. Said notification and data are transmitted to the LEXsubsystem as OUT/DATA1 packets. On receipt of said OUT/DATA1 packets,the control logic (371) within the LEX subsystem recognizes it has notreceived an acknowledgement from the device so said control logicgenerates a synthetic negative acknowledgement packet and transmits thesame as a NAK packet to the host. Said control logic (371) forwards theOUT/DATA1 packets to the REX-FPGA subsystem. The control logic (372)within the REX-FPGA subsystem forwards said OUT/DATA1 packets to theREX-Hub. The control logic (373) within the REX-Hub forwards saidOUT/DATA1 packets to the Device.

On receipt of the OUT/DATA1 packets, the control logic (374) within thedevice assembles the required acknowledgement packet and transmits thesame as a Result packet to the REX-Hub. The control logic (373) withinthe REX-Hub receives said Result packet and forwards the same packet tothe REX-FPGA subsystem. The control logic (372) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem. The controllogic (371) within the LEX subsystem stores said Result packet in itsbuffer memory.

At a later time, the control logic (370) within the host recognizes thatit has not received the requested Result and automatically retries thetransaction by generating further OUT/DATA1 packets addressed to thesame USB function and transmitting the same to the LEX subsystem. Onreceipt of the OUT/DATA1 packets, the control logic (371) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further OUT/DATA1 packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (371) alsorecognizes that said OUT/DATA1 packets are a repetition of the previousOUT/DATA1 packets and absorbs said packets.

The sequence for the Data Phase described above by the distributedcontrol logics 365–369 also serves to describe the operation of a bulkinput transfer between a high-speed host and a high-speed device.

FIG. 30 is a sequence diagram showing a control output transfer, betweena high-speed host and a high-speed device. In the Set-up Phase, thecontrol logic (360) within the Host generates a notification of deviceset-up and a data packet addressed to a particular USB function. Saidnotification and data packet are transmitted to the LEX subsystem as aSETUP packet and a DATA0 packet (SETUP/DATA0 packets). On receipt of theSETUP/DATA0 packets, the control logic (361) within the LEX subsystemrecognizes that it has not received an acknowledgement from the deviceso said control logic generates a synthetic acknowledgement packet andtransmits the same as an ACK packet to the host. Said control logic(361) forwards the SETUP/DATA0 packets to the REX-FPGA subsystem. Thecontrol logic (362) within the REX-FPGA subsystem forwards saidSETUP/DATA0 packets to the REX-Hub. The control logic (363) within theREX-Hub forwards said SETUP/DATA0 packets to the device.

On receipt of the SETUP/DATA0 packets, the control logic (364) withinthe device assembles the requested Result and transmits the same as aResult packet to the REX-Hub. The control logic (363) within the REX-Hubforwards said Result packet to the REX-FPGA subsystem. The control logic(362) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem. The control logic (361) within the LEX subsystemrecognizes that it has already sent an acknowledgement to the host andabsorbs said Result packet.

In the Data Phase, the control logic (365) within the host generates anotification of output data and a data packet, addressed to the same USBfunction as in the Set-up Phase. Said notification and data packet aretransmitted as OUT/DATA1 packets to the LEX subsystem. On receipt of theOUT/DATA1 packets, the control logic (366) within the LEX subsystemrecognizes that it has not received an acknowledgement packet from thedevice so said control logic generates a synthetic negativeacknowledgement and transmits the same as a NAK packet to the host. Saidcontrol logic (366) forwards the OUT/DATA1 packets to the REX-FPGAsubsystem. The control logic (367) within the REX-FPGA subsystemforwards said OUT/DATA1 packets to the REX-Hub. The control logic (368)within the REX-Hub forwards said OUT/DATA1 packets to the device.

On receipt of the OUT/DATA1 packets, the control logic (369) within thedevice assembles the requested Result and transmits the same to theREX-Hub as a Result packet. The control logic (368) within the REX-Hubforwards said Result packet to the REX-FPGA subsystem. The control logic(367) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (366) within the LEX subsystemstores said Result packet in its buffer memory.

At a later time, the control logic (365) within the host recognizes thatit has not received an acknowledgement from the device and automaticallyretries the transaction by issuing a further OUT packet and a furtherDATA1 packet, addressed to the same USB function. Said notification anddata are transmitted as OUT/DATA1 packets to the LEX subsystem. Onreceipt of the OUT/DATA1 packets, the control logic (366) within the LEXsubsystem recognizes that it has in its buffer memory an acknowledgementpacket that corresponds to the same function as the further OUT/DATA1packets. Said control logic (366) retrieves said stored Result packetfrom its memory and transmits the same packet to the host. Said controllogic also recognizes that said OUT/DATA1 packets are a repetition ofthe previous OUT/DATA1 packets and absorbs said packets.

The above-described process is repeated for subsequent output datanotifications from the Host by the distributed control logic (e.g. 365,366, 367, 368, 369). The control logic within the host will continue togenerate notifications of output data until the last data packet isdelivered.

In the Status Phase, the control logic (370) generates a request forinput data and transmits the same as an IN packet to the LEX subsystem.On receipt of the IN packet, the control logic (371) within the LEXsubsystem recognizes the lack of data that corresponds to the request inits buffer memory so it generates a synthetic negative acknowledgementand transmits the same as a NAK packet to the host. Said control logic(371) forwards said IN packet to the REX-FPGA subsystem. The controllogic (372) within the REX-FPGA subsystem forwards said IN packet to heREX-Hub. The control logic (373) within the REX-Hub forwards said INpacket to the device.

On receipt of the IN packet, the control logic (374) within the deviceassembles the requested data and transmits the same as a Result packetto the REX-Hub. The control logic (373) within the REX-Hub forwards saidResult packet to the REX-FPGA subsystem. On receipt of the Resultpacket, the control logic (372) within the REX-FPGA subsystem generatesa synthetic acknowledgement packet and transmits the same as an ACKpacket to the REX-Hub. The control logic (373) within the REX-Hubforwards said ACK packet to the device. The control logic (372) withinthe REX-FPGA subsystem forwards the Result packet to the LEX subsystemand the control logic (371) within the LEX subsystem stores said Resultpacket in its buffer memory.

At a later time, the control logic (370) within the host recognizes thatit has not received the requested data packet and automatically retriesthe transaction by issuing a further request for input data, addressedto the same USB function. Said request for input data is transmitted asan IN packet to the LEX subsystem. On receipt of the IN packet, thecontrol logic (371) within the LEX subsystem recognizes that it has inits buffer memory a Result packet that corresponds to the same functionas the further input request. Said control logic (371) retrieves saidstored Result packet from its memory and transmits the same packet tothe host. Said control logic also recognizes that said IN packet is arepetition of the previous IN packet and absorbs said packet. Uponsuccessful receipt of the Result packet, the control logic (370) withinthe host generates an ACK packet to acknowledge a successfultransmission. When the control logic (371) within the LEX subsystemreceives the ACK packet from the host, said control logic absorbs saidpacket.

The sequence for the Data Phase described above by the distributedcontrol logics 365-369 also serves to describe the operation of a bulkoutput transfer between a high-speed host and a high-speed device.

FIG. 31 is a sequence diagram showing a bulk input transfer, between ahigh-speed host and a full-speed device. The control logic (410) withinthe host generates a start split-transaction and a request for inputdata addressed to a particular USB function. Said startsplit-transaction and request for input data are transmitted to the LEXsubsystem as a SSPLIT packet and an IN packet (SSPLIT/IN packets). Onreceipt of the SSPLIT/IN packets, the control logic (411) within the LEXsubsystem recognizes that it has not yet received an acknowledgementfrom the device so said control logic generates a synthetic negativeacknowledgement and transmits the same to the host as a NAK packet Saidcontrol logic (411) forwards said SSPLIT/IN packets to the REX-FPGAsubsystem. The control logic (412) within the REX-FPGA subsystemforwards said SSPLIT/IN packets to the REX-Hub.

On receipt of the SSPLIT/IN packets, the control logic (413) within theREX-Hub generates an acknowledgement packet and transmits the same tothe REX-FPGA subsystem as a Result packet. The control logic (412)within the REX-FPGA subsystem forwards said Result packet to the LEXsubsystem and the control logic (411) within the LEX subsystem storessaid Result packet in its buffer memory. The control logic (413) withinthe REX-Hub absorbs said SSPLIT packet and forwards said IN packet tothe device. On receipt of said IN packet, the control logic (414) withinthe device assembles the requested data and transmits the same as aResult packet to the REX-Hub. The control logic (413) within the REX-Hubstores said Result packet in its buffer memory. On receipt of the Resultpacket, said control logic (413) generates an ACK packet to acknowledgea successful transmission.

At a later time, the control logic (410) within the host recognizes thatit has not received the requested data from the device and automaticallyretries the transaction by issuing a further start split-transaction anda request for input data addressed to the same USB function. Said startsplit-transaction and request for input data are transmitted asSSPLIT/IN packets to the LEX subsystem. On receipt of the SSPLIT/INpackets, the control logic (411) within the LEX subsystem recognizesthat it has an acknowledgement packet stored in memory from the samefunction identified by the further SSPLIT/IN packets. Said control logicretrieves the stored acknowledgement packet from memory and transmitsthe same as a Result packet to the Host. Said control logic (411) alsorecognizes that said SSPLIT/IN packets are merely a repetition of theprevious SSPLIT/IN packets and absorbs said packets.

At a later time, the control logic (410) within the host generates acomplete split-transaction and a request for input data, addressed tothe same USB function. Said complete split-transaction and request forinput data are transmitted as CSPLIT/IN packets to the LEX subsystem. Onreceipt of the CSPLIT/IN packets, the control logic (411) within the LEXsubsystem recognizes that it has not received an acknowledgment packetfrom the device so said control logic generates a synthetic NYET packetand transmits the same to the host. Said NYET packet informs the hostthat the LEX subsystem has not yet received a response from the deviceand enables said host to progress to the next transaction. The controllogic (411) within the LEX subsystem forwards said CSPLIT/IN packets tothe REX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said CSPLIT/IN packets to the REX-Hub.

On receipt of the CSPLIT/IN packets, the control logic (413) within theREX-Hub recognizes that it has in its buffer memory a Result packet thatcorresponds to the input data request. Said control logic (413)retrieves said stored Result packet and transmits the same to theREX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said Result packet to the LEX subsystem and thecontrol logic (411) within the LEX subsystem stores said Result packetin its buffer memory.

At a later time, the control logic (410) within the host recognizes thatit has not received the requested data from the device and automaticallyretries the transaction by issuing a further complete split-transactionand a request for input data, addressed to the same USB function. Saidcomplete split-transaction and request for input data are transmitted tothe LEX subsystem as further CSPLIT/IN packets. On receipt of thefurther CSPLIT/IN packets, the control logic (411) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further CSPLIT/IN packets. Saidcontrol logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (411) alsorecognizes that said CSPLIT/IN packets are merely a repetition of theprevious CSPLIT/IN packets and absorbs said packets.

The above-described process is repeated for subsequent input datarequests from the Host by the distributed control logic (e.g. 410, 411,412, 413, 414).

FIG. 32 is a sequence diagram showing a bulk output transfer, between ahigh-speed host and a full-speed device. The control logic (410) withinthe host generates a start split-transaction, a notification of outputdata, and a data packet, addressed to a particular USB function. Saidstart split-transaction, notification of output data, and data packetare transmitted to the LEX subsystem as a SSPLIT packet, an OUT packetand a DATAX packet, respectively. Said DATAX packet represents a DATA0packet or a DATA1 packet. On receipt of the SSPLIT/OUT/DATAX packets,the control logic (411) within the LEX subsystem recognizes the lack ofResult that corresponds to the input request in its buffer memory sosaid control logic generates a synthetic negative acknowledgement andtransmits the same to the host as a NAK packet. Said control logic (411)forwards said SSPLIT/OUT/DATAX packets to the REX-FPGA subsystem. Thecontrol logic (412) within the REX-FPGA subsystem forwards saidSSPLIT/OUT/DATA1 packets to the REX-Hub.

On receipt of the SSPLIT/OUT/DATAX packets, the control logic (413)within the REX-Hub generates an acknowledgement packet and transmits thesame to the REX-FPGA subsystem as a Result packet. The control logic(412) within the REX-FPGA subsystem forwards said Result packet to theLEX subsystem and the control logic (411) within the LEX subsystemstores said Result packet in its buffer memory. The control logic (413)within the REX-Hub absorbs said SSPLIT packet and forwards saidOUT/DATAX packets to the device. On receipt of said OUT/DATAX packets,the control logic (414) within the device assembles the requested Resultand transmits the same as a Result packet to the REX-Hub.

The control logic (413) within the REX-Hub stores said Result packet inits buffer memory. At a later time, the control logic (410) within thehost recognizes that it has not received the requested Result andautomatically retries the transaction by issuing furtherSSPLIT/OUT/DATAX packets addressed to the same USB function andtransmitting the same to the LEX subsystem. On receipt of theSSPLIT/OUT/DATAX packets, the control logic (411) within the LEXsubsystem recognizes that it has a Result packet stored in memory fromthe same function identified by the further SSPLIT/OUT/DATAX packets.Said control logic retrieves said stored Result packet from memory andtransmits the same packet to the Host. Said control logic (411) alsorecognizes that said SSPLIT/OUT/DATAX packets are a repetition of theprevious SSPLIT/OUT/DATAX packets and absorbs said packets.

At a later time, the control logic (410) within the host generates acomplete split-transaction and a notification of output data. Saidcomplete split-transaction and notification of output data aretransmitted to the LEX subsystem as a CSPLIT packet and an OUT packet.On receipt of the CSPLIT/OUT packets, the control logic (411) within theLEX subsystem recognizes the lack of Result that corresponds to thenotification of output data in its memory so said control logic (411)generates a NYET packet and transmits the same to the host Said NYETpacket warns the host that the LEX subsystem has not yet received aresponse from the device and enables said host to progress to the nexttransaction. Said control logic (411) forwards said CSPLIT/SETUP packetsto the REX-FPGA subsystem. The control logic (412) within the REX-FPGAsubsystem forwards said CSPLIT/OUT packets to the REX-Hub.

On receipt of the CSPLIT/OUT packets, the control logic (413) within theREX-Hub recognizes that it has a Result packet stored in memory from thesame function identified by the further CSPLIT/OUT packets. Said controllogic retrieves said stored Result packet from memory and transmits thesame packet to the REX-FPGA subsystem. The control logic (412) withinthe REX-FPGA subsystem forwards said Result packet to the LEX subsystemand the control logic (411) within the LEX subsystem stores said Resultpacket in its buffer memory.

At a later time, the control logic (410) within the host recognizes thatit has not received the requested Result and automatically retries thetransaction by issuing a further CSPLIT packet and a further OUT packetto the LEX subsystem. On receipt of the CSPLIT/OUT packets, the controllogic (411) within the LEX subsystem recognizes that it has a Resultpacket stored in memory from the same function identified by the furtherCSPLIT/OUT packets. Said control logic retrieves said stored Resultpacket from memory and transmits the same packet to the Host. Saidcontrol logic (411) also recognizes that said CSPLIT/OUT packets are arepetition of the previous CSPLIT/OUT packets and absorbs said packets.

FIG. 33 provides a sequence diagram showing a PING protocol according tothe invention.

The control logic (500) within the host generates a high-speed flowcontrol probe for a bulk/control endpoint, addressed to a particular USBfunction, and transmits the same to the LEX subsystem as a PING packet.On receipt of said PING packet, the control logic (501) within the LEXsubsystem recognizes that it has not yet received an acknowledgment fromthe device corresponding to said PING packet. Said control logicgenerates a synthetic negative acknowledgment packet and transmits thesame as a NAK packet to the host. Said control logic (501) forwards saidPING packet to the REX-FPGA subsystem. The control logic (502) withinthe REX-FPGA subsystem forwards said PING packet to the REX-Hub. Thecontrol logic (503) within the REX-Hub forwards said PING packet to theDevice.

Upon successful receipt of said PING packet, the control logic (504)within the device generates an acknowledgment and transmits the same tothe REX-Hub as a Result packet. The control logic (503) within theREX-Hub forwards said Result packet to the REX-FPGA subsystem. Thecontrol logic (502) within the REX-FPGA subsystem forwards said Resultpacket to the LEX subsystem and the control logic (501) within the LEXsubsystem stores said Result packet in its buffer memory.

At a later time, the control logic (500) within the host realizes thatit has not received an acknowledgment from the device and automaticallyretries the transaction by issuing a further high-speed flow controlprobe to the same USB function. Said flow control probe is transmittedto the LEX subsystem as a PING packet On receipt of said PING packet,the control logic (501) within the LEX subsystem recognizes that it hasan acknowledgment packet stored in its memory from the same functionidentified by the further PING packet. Said control logic retrieves saidacknowledgment packet from its buffer memory and transmits the same tothe host as a Result packet Said control logic (501) also recognizessaid further PING packet is merely a repetition of the previous PINGpacket and absorbs said packet.

The above-described process is repeated for subsequent high-speed flowcontrol probes from the Host by the distributed control logic (e.g. 500,501, 502, 503, 504).

Thus, it is apparent that there have been provided, in accordance withthe present invention, USB devices which fully, or at least partially,satisfy the means, objects, and advantages over the prior art as setforth hereinbefore. Therefore, having described specific embodiments ofthe present invention, it will be understood that alternatives,modifications and variations thereof may be suggested to those skilledin the art, and that it is intended that the present specificationembrace all such alternatives, modifications and variations as fallwithin the scope of the appended claims.

Additionally, for clarity and unless otherwise stated, the word“comprise” and variations of the word such as “comprising” and“comprises”, when used in the description and claims of the presentspecification, is not intended to exclude other additives, components,integers or step.

1. An enhanced high-speed method for transmitting a data stream betweena high speed host controller and a full speed or low speed peripheraldevice over an extended distance, on a signal distribution system,wherein said transmission of said data stream is conducted using aUSB-Extended Range Protocol (USB-ERP), wherein data flows from saidperipheral device to said host controller, and said data stream beingtransmitted is encapsulated in split transactions, said methodcomprising: a. receiving, at a local expander, an original requcst tostart the transfer of a data packet from said peripheral device to saidhost controller; b. optionally, generating a negative acknowledgementpacket at said local expander and forwarding said negativeacknowledgement packet to said host controller; c. forwarding saidoriginal request for the start of data transfer from said local expanderto a Remote Expander-Field Programmable Gate Array (REX-FPGA) over atransmission system; d. receiving at said REX-FPGA said forwardedoriginal request for the start of data transfer; e. delivering saidforwarded original request for the start of data transfer from saidREX-FPGA to a USB hub; f. receiving at said REX-FPGA an acknowledgementof the start of data transfer from said USB hub; g. forwarding saidacknowledgement of the start of data transfer from said REX-FPGA to saidlocal expander; h. receiving at said local expander said forwardedacknowledgement of the start of data transfer; i. storing in a packetbuffer at said local expander, said forwarded acknowledgement of thestart of data transfer; j. optionally receiving, at said local expander,a subsequent request to start the transfer of a data packet from saidperipheral device to said host controller; and i. retrieving from saidpacket buffer said stored acknowledgement of the start of data transfer;ii. delivering said retrieved acknowledgement to said host controller;k. receiving, at a local expander, an original request to complete thetransfer of a data packet from said peripheral device to said hostcontroller; l. generating a synthetic not-yet packet at said localexpander and forwarding said synthetic not-yet packet to said hostcontroller; m. forwarding said original request for the completion ofdata transfer from said local expander to said REX-FPGA over atransmission system; n. receiving at said REX-FPGA said forwardedoriginal request for the completion of data transfer; o. delivering saidforwarded original request for the completion of data transfer from saidREX-FPGA to a USB hub; p. receiving at said REX-FPGA a completed datapacket from said USB hub: q. forwarding said completed data packet fromsaid REX-FPGA to said local expander; r. receiving at said localexpander said forwarded completed data packet; s. storing in a packetbuffer at said local expander, said forwarded completed data packet; t.receiving, at said local expander. a subsequent request to complete thetransfer of a data packet from said peripheral device to said hostcontroller; and i. retrieving, from said packet buffer, said storedcompleted data packet; and ii. delivering said retrieved completed datapacket to said host controller.
 2. An apparatus as claimed in claim 1wherein said extended distance exceeds 5 meters.
 3. A method as claimedin claim 1 wherein said transmission of said data stream is incompliance with Revision 2.0 of the USB specification, with theexception of the distance between said host controller and saidperipheral device.
 4. An enhanced high-speed method for transmitting adata stream between a high speed host controller and a full speed or lowspeed peripheral device aver an extended distance, on a signaldistribution system, wherein said transmission o:F said data stream isconducted using a USB-Extended Range Protocol, wherein data flows fromsaid host controller to said peripheral device, and said data streambeing transmitted is encapsulated in split transactions, said methodcomprising: a. receiving, at a local expander, an original notificationof the start of data transfer from said host controller to saidperipheral device; b. optionally, generating a negative acknowledgmentpacket at said local expander and forwarding said negativeacknowledgment packet to said host controller; c. forwarding saidoriginal notification of the start of data transfer from said localexpander to a Remote Expander—Field Programmable Gate Array (REX-FPGA)over a transmission system; d. receiving at said REX-FPGA said forwardedoriginal notification of the start of data transfer; e. delivering saidforwarded original notification of the start of data transfer from saidREX-FPGA to a USB hub; f. receiving at said REX-FPGA an acknowledgementof the start of data transfer from said USB hub; g. forwarding saidacknowledgement of the start of data transfer from said REX-FPGA to saidlocal expander; h. receiving at said local expander said forwardedacknowledgement of the start of data transfer; i. storing in a packetbuffer at said local expander, said forwarded acknowledgement of thestart of data transfer; j. receiving, at said local expander, asubsequent notification of the start of data transfer from said hostcontroller to said peripheral device; and i. retrieving from said packetbuffer said stored acknowledgement of the start of data transfer; andii. delivering said retrieved acknowledgement to said host controller;k. optionally receiving, at a local expander, an original request tocomplete the transfer of a data packet from said host controller to saidperipheral device; l. generating a synthetic not-yet packet at saidlocal expander and forwarding said synthetic not-yet packet to said hostcontroller; m. forwarding said original request for the completion ofdata transfer from said local expander to said REX-FPGA over atransmission system; n. receiving at said REX-FPGA said forwardedoriginal request for the completion of data transfer; o. delivering saidforwarded original request for the completion of data transfer from saidREX-FPGA to a USB hub; p. receiving at said REX-FPGA an acknowledgementof the completion of data transfer from said USB hub; q. forwarding saidacknowledgement of the completion of data transfer from said REX-FPGA tosaid local expander; r. receiving at said local expander said forwardedacknowledgement of the completion of data transfer; s. storing in apacket buffer at said local expander, said forwarded acknowledgement ofthe completion of data transfer; t. receiving, at said local expander, asubsequent request to complete the transfer of a data packet from saidhost controller to said peripheral device; and i. retrieving, from saidpacket buffer, said stored acknowledgement of the completion of datatransfer; and ii. delivering said retrieved acknowledgement of thecompletion of data transfer to said host controller.
 5. An apparatus asclaimed in claim 4 wherein said extended distance exceeds 5 meters.
 6. Amethod as claimed in claim 4 wherein said transmission of said datastream is in compliance with Revision 2.0 of the USB specification, witthe exception of the distance between said host controller and saidperipheral device.
 7. An enhanced high-speed method for transmitting adata stream between a high speed host controller and a peripheral deviceover an extended distance, on a signal distribution system, wherein saidtransmission of said data stream is conducted using a USB-Extended RangeProtocol (USB-ERP), and wherein data flows from said peripheral deviceto said host controller, said peripheral device operates at high speedand in high bandwidth mode, and wherein multiple data packets aretransmitted in a single micro-frame, said method comprising: a.receiving at a local expander a first request for data transfer fromsaid peripheral device to said host controller; b. optionally,generating a null data packet or a negative acknowledgement packet atsaid local expander and forwarding said null data packet or saidnegative acknowledgement packet to said host controller; c. forwardingsaid first request for data transfer from said local expander to aRemote Expander—Field Programmable Gate Array (REX-FPGA) over atransmission system; d. receiving at said REX-FPGA said forwarded firstrequest for data transfer; e. delivering said forwarded first requestfor data transfer from said REX-FPGA to a USB hub; f. receiving at saidREX-FPGA a first data packet from said USB hub; g. forwarding said firstdata packet from said REX-FPGA to said local expander; h. receiving atsaid local expander said first data packet; i. storing in a packetbuffer at said local expander, said first data packet; j. repeatingsteps (b) through (i) in response to a second request for data transferfrom said peripheral device to said host controller; k. repeating steps(b) through (i) in response to a third request for data transfer fromsaid peripheral device to said host controller; l. receiving, at a localexpander, a start of frame packet; m. receiving at a local expander afourth request for data transfer from said peripheral device to saidhost controller; and i. retrieving from said packet buffer said storedfirst data packet; ii. delivering said retrieved first data packet tosaid host controller; n. repeating steps (c) through (i) for said fourthrequest for data transfer; o. receiving at a local expander a fifthrequest for data transfer from said peripheral device to said hostcontroller; and i. retrieving from said packet buffer said stored seconddata packet; ii. delivering said retrieved second data packet to saidhost controller; p. repeating steps (c) through (i) for said fifthrequest for data transfer; q. receiving at a local expander a sixthrequest for data transfer from said peripheral device to said hostcontroller; and i. retrieving from said packet buffer said stored thirddata packet; ii. delivering said retrieved third data packet to saidhost controller; r. repeating steps (c) through (i) for said sixthrequest for data transfer; and s. repeating steps (l) through (r) for aslong as said host controller continues to issue requests for datatransfer.
 8. An apparatus as claimed in claim 7 wherein said extendeddistance exceeds 5 meters.
 9. A method as claimed in claim 7 whereinsaid transmission of said data stream is in compliance with Revision 2.0of the USB specification, with the exception of the distance betweensaid host controller and said peripheral device.
 10. An enhancedhigh-speed method for transmitting a data stream between a high speedhost controller and a peripheral device over an extended distance, on asignal distribution system, wherein said transmission of said datastream is conducted using a USB-Extended Range Protocol, and whereindata flows from said host controller to said peripheral device, saidperipheral device operates at high speed and in high bandwidth mode, andwherein multiple data packets are transmitted in a single micro-frame,said method comprising: a. receiving, at a local expander, a firstnotification of data transfer from said host controller to saidperipheral device; b. optionally, generating a positive acknowledgementpacket or a negative acknowledgement packet at said local expander andforwarding said positive acknowledgement packet or said negativeacknowledgement packet to said host controller; c. forwarding said firstnotification of data transfer from said local expander to a RemoteExpander—Field Programmable Gate Array (REX-FPGA) over a transmissionsystem; d. receiving at said REX-FPGA said forwarded first notificationof data transfer; e. delivering said forwarded first notification ofdata transfer from said REX-FPGA to a USB hub; f. receiving at saidREX-FPGA a first acknowledgement of data transfer from said USB hub; g.forwarding said first acknowledgement of data transfer from saidREX-FPGA to said local expander; h. receiving at said local expandersaid forwarded first acknowledgement of data transfer; i. storing in apacket buffer at said local expander, said forwarded firstacknowledgement of data transfer; j. repeating steps (a) through (i) inresponse to a second notification of data transfer from said hostcontroller to said peripheral device; k. repeating steps (a) through (i)in response to a third notification of data transfer from said hostcontroller to said peripheral device; l. receiving, at a local expandera start of frame packet; m. receiving at a local expander a fourthnotification of data transfer from said host controller to saidperipheral device; and i. retrieving from said packet buffer said storedfirst acknowledgement packet; ii. delivering said retrieved firstacknowledgement packet to said host controller; n. repeating steps (c)through (i) for said fourth notification of data transfer; o. receivingat a local expander a fifth notification of data transfer from said hostcontroller to said peripheral device; and i. retrieving from said packetbuffer said stored second acknowledgement packet; ii. delivering saidretrieved second acknowledgement packet to said host controller; p.repeating steps (c) through (i) for said fifth notification of datatransfer; q. receiving at a local expander a sixth notification of datatransfer from said host controller to said peripheral device; and i.retrieving from said packet buffer said stored third acknowledgementpacket; ii. delivering said retrieved third acknowledgement packet tosaid host controller; r. repeating steps (c) through (i) for said sixthrequest for data transfer; s. repeating steps (l) through (r) for aslong as said host controller continues to issue notifications of datatransfer.
 11. An apparatus as claimed in claim 10 wherein said extendeddistance exceeds 5 meters.
 12. A method as claimed in claim 10 whereinsaid transmission of said data stream is in compliance with Revision 2.0of the USB specification, with the exception of the distance betweensaid host controller and said peripheral device.